ht-cli: uptime monitoring from the command line and CI

Mint a token on your HostTracker profile, then run ht-cli auth login: it prompts for the token, verifies it against the API and stores it in a YAML config file under the OS configuration directory, written 0600 because it holds a credential. Named profiles let several accounts coexist - ht-cli auth login --profile staging keeps a second token beside the default one, and --profile selects which to use per command. A CI job usually skips the login step entirely and exports HT_TOKEN as an environment variable instead, which ht-cli reads with no config file at all.

Three: table, json and yaml, chosen with --output or -o. Left unset, ht-cli picks for you - a table when the output goes to a terminal, json the moment it is piped or redirected - so ht-cli monitors list | jq needs no flag and neither does reading the same command yourself. The table view is a reading aid: it shows scalar fields, folds a nested object or array into a short {n} or [n] marker, renders Unix-second timestamps as readable instants, and prints how many rows matched. Anything a script depends on should ask for json explicitly rather than rely on the pipe detection.

Yes - it is built for exactly that. Export HT_TOKEN as a secret rather than logging in interactively, use --output json for anything a later step parses, and ht-cli check run <url> --wait for a synchronous pass/fail gate on a deploy. The official HostTracker Check GitHub Action (HostTracker/check-action@v1) wraps ht-cli for the common cases - check, assert-up and create-monitor modes - and downloads a pinned, checksum-verified release of the CLI itself, so a workflow needs no separate install step.

It is the API, packaged as commands. Every one of the 139 generated commands is a thin wrapper over one REST API v2 operation, built on the same Go SDK a developer would use directly - the bearer token, the automatic Idempotency-Key on writes, the retry ladder for 429 and 503, and the RFC 9457 problem-document errors are the SDK's behaviour either way. ht-cli api is the escape hatch for anything not covered by a named command: ht-cli api GET /monitor --query limit=5 --query state=down reaches the raw surface directly, which also makes it the fastest way to reproduce a call from the reference documentation at a terminal.

0 means the command did what it was asked, and 1 is a failure with no more specific code. Everything else names the reason: 2 is a command-line mistake (an unknown flag or a bad value), 3 is a missing, rejected or under-scoped credential, 4 means the address named nothing, 5 means the API refused the request outright, 6 means throttled or out of quota, and 7 means the API could not be reached. A 429 response is deliberately split between 6's two causes - rate_limited is worth retrying, quota_exceeded is not - and only the printed problem code, not the exit code alone, tells them apart; --verbose prints every request's status and rate-limit budget to stderr.

Whichever channel installed it manages the update: sudo apt upgrade on the apt repository, sudo dnf upgrade on the dnf one, brew upgrade ht-cli through Homebrew, scoop update ht-cli on Windows, or a fresh docker pull of the ghcr.io/hosttracker/ht-cli image. The curl script and the release-binary route are reinstalls - rerun the installer, or download the newer archive and replace the binary on PATH. ht-cli version prints what is currently installed if you need to check before deciding.

Yes. A monitor is a JSON document, so ht-cli monitors create --json @monitor.json or the bulk equivalent, ht-cli monitors bulk-create --json @monitors.json, turns a file in your repository into live monitoring - and running it again does not duplicate anything the API already recognises. The HostTracker Check GitHub Action's create-monitor mode does the same from a workflow, looking for an existing monitor with the same url and name before creating a new one. Export the current state back to a file at any time with ht-cli monitors list --output json --all, which is the fastest way to start the file from monitors that already exist.