The official command-line interface for UptimeRobot. Manage uptime monitors, incidents, status pages, maintenance windows, and alert contacts from your terminal, scripts, CI pipelines, or coding agents — readable tables when you're interactive, stable JSON when you're automating.
Built on the UptimeRobot API v3. The CLI combines human-friendly commands with structured output, local validation, and safe automation defaults.
- Manage monitors, incidents, status pages, maintenance windows, alert contacts, integrations, tags, and more.
- Create each monitor type through a dedicated command such as
monitors create httpormonitors create keyword. - Use readable tables interactively and stable JSON or JSONL for automation.
- Inspect and validate monitor requests locally before sending them.
UptimeRobot CLI requires Node.js 22.12 or newer.
npm install --global @uptimerobot/cliWith pnpm:
pnpm add --global @uptimerobot/cliVerify the installation:
uptimerobot --version
uptimerobot --help--version prints one human-readable line. The version command reports the same facts through the normal output flags, so a script asserting a minimum version reads a field instead of parsing a sentence:
uptimerobot version --json
# {"version":"1.0.0","platform":"darwin-arm64","node":"24.12.0"}Install the UptimeRobot AI skills for supported coding agents:
uptimerobot skills installThe CLI shows the exact external command and requires confirmation before handing the terminal to npx skills. npx may download and execute the third-party skills package, which can write skill files into your project or agent directories. The installer prompts for the skills, agents, and installation scope. In a non-interactive environment, run npx skills add uptimerobot/ai directly after reviewing it.
Create an API key, then save it in your operating system's secure credential store:
uptimerobot auth loginThe CLI prompts for the key with masked input and validates it before saving, so the key never appears in shell history. For scripts, provide it through the environment instead:
UPTIMEROBOT_API_KEY='your-api-key' uptimerobot auth loginThe key is stored in macOS Keychain, Windows Credential Manager, or an available Linux keyring. When no OS keyring is available — common on minimal or headless Linux — the key is saved in plaintext at ~/.config/uptimerobot/credentials.json with owner-only 0600 permissions. Set UPTIMEROBOT_CONFIG_DIR to change that location. Prefer a preconfigured environment or secret manager instead of typing secrets directly into shell history.
For CI, containers, and other temporary environments, provide the key without storing it:
export UPTIMEROBOT_API_KEY='your-api-key'
uptimerobot monitors listCredentials are resolved from --api-key, then UPTIMEROBOT_API_KEY, then the stored key. Run uptimerobot auth logout to remove the stored credential.
List monitors:
uptimerobot monitors listCreate an HTTP monitor:
uptimerobot monitors create http \
--name checkout-api \
--url https://checkout.example.com \
--interval 60 \
--timeout 30 \
--method GET \
--check-ssl \
--follow-redirectsInspect or delete it:
uptimerobot monitors get 797054213
uptimerobot monitors delete 797054213 --confirmHelp is available at every level of the command tree:
uptimerobot help
uptimerobot monitors --help
uptimerobot monitors create --help
uptimerobot monitors create keyword --help
uptimerobot incidents comments create --helpuptimerobot help <command-or-topic> is equivalent to the --help flag, so uptimerobot help monitors create and uptimerobot monitors create --help print the same page.
Monitor creation commands expose only the fields relevant to their type and supply the API monitor type automatically. Command help includes accepted values, required fields, defaults, constraints, and examples from the packaged API contract.
Typed flags cover normal use. Full API request bodies remain available when needed:
uptimerobot monitors create http --body @monitor.json
uptimerobot monitors update 797054213 --set interval=120
uptimerobot monitors create http --body - < monitor.json--body is a base document, and typed flags and --set are applied on top of it. Those two are peers, so giving the same field a different value with both is an error rather than a silent win for one of them:
uptimerobot monitors create http --name checkout-api --set friendlyName=checkout
# INVALID_INPUT: friendlyName received conflicting values:
# --name checkout-api and --set friendlyName=checkout. Pass only one.A heartbeat monitor stays silent until something pings it, so normalized output carries a derived pingUrl — the address that job should call. Both it and the url it is built from are secrets, so both are redacted unless you ask for them:
uptimerobot monitors get 803704830 --json
# {"type":"HEARTBEAT","id":803704830,"url":"[REDACTED]","pingUrl":"[REDACTED]"}
uptimerobot monitors get 803704830 --json --reveal-secrets
# {"type":"HEARTBEAT","id":803704830,"url":"997c8970…","pingUrl":"https://heartbeat.uptimerobot.com/m803704830-997c8970…"}Reach for --reveal-secrets when wiring up the job that pings it, which is normally once per monitor. Anyone holding the ping URL can report the heartbeat on your behalf, so a leaked one keeps a dead service looking alive with no alert raised. url on every other monitor type is a target address, not a secret, and is never redacted.
The URL is composed from the monitor's id and url, where url carries the monitor's token rather than a target address. Set UPTIMEROBOT_HEARTBEAT_URL to point at a different host. The field is derived by the CLI, not returned by the API, so --raw does not include it.
Inspect a monitor request contract or print a validated example without credentials or network access:
uptimerobot monitors schema keyword
uptimerobot monitors schema keyword --exampleAdd --dry-run to compile and validate a JSON request without authenticating or sending it:
uptimerobot monitors create http --body @monitor.json --dry-runDry-run output contains the final method, path, content type, and body. Recognizable credential fields are redacted. Local validation cannot verify account entitlements, referenced resource IDs, or other server-owned rules.
Interactive terminals use tables by default. Piped, redirected, and agent-driven commands use normalized JSON by default.
| Option | Output |
|---|---|
--json |
Normalized JSON |
--format jsonl |
One normalized resource per line |
--format table |
Human-readable table |
--format plain |
Headerless, tab-separated rows |
--raw |
Untouched API response as JSON |
--reveal-secrets |
Credential-like fields shown in full |
Recognizable credential fields in a response, such as httpPassword, print as [REDACTED] in every format, and a stderr notice names what was hidden. Pass --reveal-secrets to print the values instead. --raw skips redaction along with the rest of normalization. Machine-readable error envelopes are redacted the same way but unconditionally, because failure output is what ends up in bug reports and CI logs; --reveal-secrets does not lift it. Redaction matches field names, so a credential quoted inside an error message is not covered.
Set UPTIMEROBOT_OUTPUT to json, jsonl, table, or plain to choose a default. Use --agent or UPTIMEROBOT_AGENT=1 to identify agent execution explicitly. A truthy CI environment variable identifies CI execution independently.
Normalized collection JSON contains items and nextCursor. The CLI does not follow pagination automatically; pass a returned cursor through --cursor for the next page. Collection commands also support --columns and --all. Column selection never changes JSON, JSONL, or raw output, and --all may expose sensitive API fields.
Machine-readable failures are emitted as JSON on stderr. Stdout remains empty, except for monitors bulk commands, which print their per-item results on stdout even when the operation failed.
The exit code identifies the failure:
| Exit code | Meaning |
|---|---|
0 |
Success |
1 |
Generic failure, including a bulk operation where every item failed (BULK_FAILED) |
2 |
Invalid input, rejected either locally or by the API (HTTP 400 or 422) |
3 |
Bulk operation where some items failed (BULK_PARTIAL_FAILURE) |
4 |
Unauthenticated (HTTP 401) |
5 |
Forbidden (HTTP 403) |
6 |
Not found (HTTP 404) |
7 |
Rate limited (HTTP 429) |
8 |
Conflict with the current state (HTTP 409) |
Exit code 2 covers both a request the CLI rejected before sending and one the API rejected as invalid, so it always means the input is wrong. Along with 8, it says the request will not succeed as sent and should be changed rather than repeated; 1 and 7 are the failures a plain retry may clear.
The error envelope's code is HTTP_<status> whenever status is present, and a CLI symbol such as INVALID_INPUT or AUTH_REQUIRED otherwise, so status distinguishes a failure the API reported from one the CLI raised. When the API supplies an error code of its own it is passed through verbatim as apiCode and is never interpreted; it is not part of the CLI's contract, because the API does not currently document those codes:
uptimerobot monitors get 999999999 --json
# {"error":{"apiCode":"000-004","code":"HTTP_404","message":"Monitor not found","status":404}}Branch on code or status. Read apiCode only for diagnostics, and use --raw for the untouched API response.
monitors bulk pause, monitors bulk start, and monitors bulk update report per-monitor outcomes in an HTTP 201 response, so a failure is only visible in the body. The CLI inspects it and exits non-zero, listing the failed entries in the error envelope's details.
Those three commands report acceptance rather than completion. The API answers success for every matched monitor as soon as the write is accepted; it carries no operation id, and nothing in the response distinguishes queued from applied. Exit code 0 therefore means the request was accepted, not that the monitors have changed. A pipeline that pauses monitors before a deploy should confirm with uptimerobot monitors get <id> before it continues.
Destructive commands prompt in an interactive terminal. Agents and non-interactive processes must pass --confirm explicitly:
uptimerobot monitors delete 797054213 --confirm --jsonThe CLI retries only safe GET and HEAD requests. It does not retry POST, PATCH, or DELETE; retain returned resource IDs before deciding to repeat a mutation.
This project uses pnpm and oclif.
pnpm install
pnpm build
pnpm format:check
pnpm lint
pnpm typecheck
pnpm testThe command tree is generated from openapi/openapi.yaml, which tracks the published UptimeRobot OpenAPI contract. Run pnpm openapi:generate after updating the snapshot. Generated command files and operation metadata should not be edited directly.
For bugs and feature requests, open a GitHub issue. Include the CLI version, command, output mode, and a sanitized error response when possible. Never include an API key.
Licensed under the Apache License 2.0.