Managing monitors has meant one of two things: the dashboard, or writing your own API calls. There is now a third. The official UptimeRobot CLI is live on npm, and it drives every monitor, incident, and status page in your account from the shell you already have open.
It is free, open source under Apache 2.0, and works on every plan including the free one.
From install to your first monitor in 60 seconds
You need Node.js 22.12 or newer and an API key from your dashboard integrations page. Then four commands, and your checkout endpoint is under a 60-second check.
# Install, log in, create a monitor, see it running.
npm install --global @uptimerobot/cli
uptimerobot auth login
? UptimeRobot API key ******************** Saved to your system keychain.
uptimerobot monitors create http \
--name checkout-api \
--url <https://checkout.example.com> \
--interval 60 \
--timeout 30
uptimerobot monitors list
ID STATUS NAME TYPE TARGET INTERVAL IN STATE TAGS
797054213 UP checkout-api HTTP <https://checkout.example.com> 1m 4m -
797054180 UP marketing-www HTTP <https://example.com> 5m 21d prod
The login prompt masks the key and stores it in your macOS Keychain, Windows Credential Manager, or Linux keyring, so it never lands in your shell history.
Why a first-party CLI
Community-built wrappers exist, and they share a problem. They are written by hand against an API that keeps moving, and nobody is on the hook when the two drift apart.
This one is generated from UptimeRobot’s published API v3 contract rather than typed out. New fields and endpoints arrive through the generator instead of waiting on someone to notice. That is also why the coverage is wide rather than curated: over 70 commands across 11 groups, with a dedicated create command for each of the nine monitor types.
Monitors, incidents, uptime and response-time stats, status pages and their announcements, maintenance windows, monitor groups, alert contacts, integrations, and tags. If API v3 exposes it, the CLI has a command for it.
You do not have to memorize any of that. Start with uptimerobot --help and keep asking. Help works at every level of the command tree and prints the required fields, accepted values, defaults, and constraints straight from the API contract.
Built for CI/CD
Monitoring becomes something you commit, not something someone remembers to do after the deploy.
Set UPTIMEROBOT_API_KEY in your pipeline secrets and skip the login step, so no credential is stored on the runner. Commands return real exit codes, with distinct ones for invalid input, authentication and permission failures, rate limiting, and a bulk job where some items went through and others failed. Your pipeline branches on the code instead of parsing text.
Output follows the context. Run a command by hand and you get a readable table. Pipe it, redirect it, or run it in CI/CD and you get normalized JSON, with no flag to remember. Credential fields such as an HTTP monitor’s password print as [REDACTED] in every format, with a note on stderr naming what was hidden, so your build logs stay clean by default.
A full GitHub Actions job that creates a monitor for a freshly deployed endpoint is on the CLI page.
Safe to run under an agent
An agent driving a CLI does not read warnings, so the guardrails sit in the tool rather than in the docs.
- Destructive commands stop and ask. In a terminal you get a prompt. An agent or any other non-interactive process has to pass
--confirmexplicitly, so a delete never happens as a side effect. --dry-runvalidates a write locally, with no API key and no network call, then prints the exact method, path, and body it would have sent.- Only GET and HEAD are retried. A create that times out will not quietly produce two monitors.
- Agents get JSON without being told to ask for it, so there is no table for them to misparse.
If you would rather your agent worked from the real command contract than guessed at flags, uptimerobot skills install drops UptimeRobot’s 24 AI skills into the coding agent you already use. You pick which ones and where they go, and the CLI shows you the exact external command before it runs anything. The skills are open source at github.com/uptimerobot/ai.
CLI, MCP, Terraform, or the API
Four ways into the same account, doing four different jobs. Most people who want one end up wanting two.
| Surface | Reach for it when |
|---|---|
| CLI | You want repeatability. A command you can script, commit, and run the same way every time, by hand or in a pipeline. |
| MCP | You want conversation. You ask a question in plain language and your assistant answers from your account. |
| Terraform | Your monitoring is part of a declared infrastructure state that gets planned, applied, and drift-checked with everything else. |
| API v3 | You are building something of your own, in a language or a runtime the CLI does not fit into. |
Where the reference docs live
This post is the announcement. It is not the page to come back to when you need to remember a flag, and we are not going to keep it current with the command surface. Three places to bookmark instead:
- The CLI page for install steps, the CI/CD recipe, and the questions people ask first.
- The GitHub readme for the full command reference, output modes, exit codes, and safety behavior. It ships with the tool, so it updates when the tool does.
- The API v3 docs for the contract the CLI is generated from.
It works on the free plan
The CLI is free and open source, and it works with every UptimeRobot account. Your plan sets the limits it runs against, how many monitors you can have and how often they check. It does not change what the CLI can do.
The free plan covers 50 monitors at 5-minute checks, and it is available for any use, commercial included, inside our Fair Use Policy.
What’s next
This is the first step. Automatic setup and deeper agent integration are on the way.
Questions we expect
Do I have to stop using the dashboard?
No. The CLI and the dashboard read and write the same account. Create a monitor in your terminal and it appears in the dashboard, pause it in the dashboard and the CLI reports it paused. Use whichever is closer to hand.
Does this replace the API or the MCP server?
No, it sits next to them. MCP is for asking questions in plain language. The API is for building your own thing. The CLI is for commands you can script, commit, and rerun. Plenty of teams use two of the three.
What happens to my scripts when the API changes?
The command tree is generated from the published OpenAPI contract, so new fields and endpoints arrive through the generator rather than through a hand-written update. Existing commands keep working. When something does change, it changes in the readme that ships with the tool.
Where do I report a bug?
Open an issue at github.com/uptimerobot/uptimerobot-cli/issues, or email support@uptimerobot.com if you would rather not use GitHub. Include the CLI version, the command, the output mode, and the error. Never include your API key.
Install it
One command, and your monitoring is scriptable.
Install the CLI or read the full docs on Github.
