@coldtea/monitoring — the cmon CLI

Production monitoring from the command line: what monitoring filed, the latest daily brief, whether a repository is running or paused, and the one operational write — pause and resume.

The package installs two names for the same binary: coldtea-monitoring, and cmon for short — fewer tokens for the agents that call it most.

Install

npm install -g @coldtea/monitoring
cmon --version

Needs Node 20.6 or newer. Zero runtime dependencies.

Auth

Create an API key in the Coldtea app with a Monitoring scope, then:

export COLDTEA_API_KEY=coldtea_sk_…
cmon whoami

monitoring:read covers repositories, settings and the brief; monitoring:write covers pause and resume. cmon issues reads the task API, so it also needs tasks:read.

Getting started

cmon repos                  # what is monitored, and each repository's id
cmon brief                  # what the latest daily run did and filed
cmon issues --since 24h     # what monitoring filed lately
cmon pause                  # migration week: stop new work
cmon resume                 # pick the schedule back up

With one repository monitored, --repo is never needed. With several, pass --repo <id> from cmon repos or set COLDTEA_MONITORING_REPO.

Issues are tasks

Monitoring files its findings as tasks carrying the monitoring label, so cmon issues is the task listing with that label pinned — the same rows ctask list --label monitoring answers, with the same filters (--since, --state-type, extra --label values combining as AND). Any id it prints opens with ctask get <id>.

Exit codes

0 done · 2 couldn't do it (retry) · 3 conflict · 4 auth/config (never retry). There is no exit 1: a paused repository, or issues existing, is state, not a verdict — that code belongs to QA.

Machine output

--json prints one document on stdout in the API's own envelope, { "data": …, "meta": { "requestId": … } }; errors go to stderr in the same shape. Quote meta.requestId when reporting a problem.