Operators

Using the Operator CLI in production

Real workflows central station operators run from the terminal.

10 min read

Using the Operator CLI in production

The Monitoring Portal is great. The terminal is faster. This guide walks through the real workflows operators use opcli for once they've been on it for a week.

Install once

brew install chekt/tap/opcli
opcli login                # opens browser; OAuth
opcli config set tenant my-monitoring-co

The morning routine

opcli alarms --active --priority high   # what's open right now
opcli incidents --since "1h" --json | jq '.[] | .id'
opcli health                            # device status across all sites

Most operators alias these into morning and run it at start-of-shift.

Acknowledging in batches

When a sensor goes haywire and floods, you can ACK the batch in one shot:

opcli alarms --device dev_8h2j3kfm --status new \
  | opcli alarm acknowledge --stdin --reason "false-positive: sensor recalibration"

The CLI is pipe-friendly by design. JSON in, JSON out.

Dispatch

opcli dispatch guard --to "Main Entrance" --from-alarm A-10293

CHeKT routes the dispatch to the nearest available guard service tied to that site. The CLI returns the dispatch ID, ETA, and a live tracking URL.

Live camera

opcli camera "Main Entrance" --live --layout grid

This opens an mpv window with the live feed. On macOS, you can pipe it into QuickLook.

Audit-ready logs

Every command is logged with timestamp, operator, target, and result. Pull the audit log straight from the CLI:

opcli audit --operator $USER --since 24h

When to use the CLI vs the Portal

Workflow	Use this
First-time triage	Portal — visual context.
Bulk acknowledgement	CLI — one pipe.
Automated dispatches	CLI from a queue worker.
Compliance audits	CLI — `--json` is grep-able.

The CLI is not a replacement for the Portal. It's the second tool every operator picks up after they've outgrown clicking.