Letting an AI agent run your uptime monitoring

Two surfaces, one set of rules

Which surface you reach for depends on what is doing the reaching, not on what you want done. Both run the same shared code for team resolution, payloads, and validation, and both take the same tokens, so they cannot drift.

A monitor an agent creates over MCP is the row a curl call reads back a second later, field for field. The references live at undownable.com/docs/mcp and undownable.com/docs/api.

Workflow: a deploy script opens a window, then closes it

The highest value thing to automate. A window suppresses checks and alerts for the monitors it covers, keeps that span out of your uptime figures, and shows maintenance rather than an outage on status pages. Unlike a pause it ends itself, so a script that dies halfway leaves you monitored rather than blind:

WINDOW=$(curl -sS -X POST https://undownable.com/api/v1/maintenance-windows \
  -H "Authorization: Bearer $UNDOWNABLE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"team": "acme", "name": "Deploy", "tag": "api", "duration_minutes": 120}' \
  | jq -r .data.id)

# ... run the deploy ...

curl -sS -X POST https://undownable.com/api/v1/maintenance-windows/$WINDOW/end \
  -H "Authorization: Bearer $UNDOWNABLE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"team": "acme"}'

The scope is exactly one of monitor_ids, a tag, or all_monitors; the end is ends_at or duration_minutes, up to 30 days. A conversational agent does the same from a sentence: ask it to open a 2 hour window for the api tag before tonight's deploy and it calls create-maintenance-window, then end-maintenance-window when you say you are done.

Workflow: an agent triages an incident

When an alert fires, the useful question is not whether something is down but what changed and how often this happens. Two calls answer it: the first lists what is broken now, the second returns one monitor in detail (config with secrets masked, uptime over 24 hours, 7 days, and 30 days, and five recent incidents with cause and duration).

curl -sS -H "Authorization: Bearer $UNDOWNABLE_TOKEN" \
  "https://undownable.com/api/v1/incidents?ongoing_only=true"

curl -sS -H "Authorization: Bearer $UNDOWNABLE_TOKEN" \
  "https://undownable.com/api/v1/monitors/01JMONITORULID?team=acme"

Enough for an agent to say something worth reading: this monitor failed four times this month, always with a TLS handshake error, and 30 day uptime is 99.1 percent against 99.9 elsewhere on the host. A token holding only monitors:read and incidents:read does all of it and changes nothing.

Workflow: CI provisions a monitor for every new service

Nobody remembers to add the monitor. Make the pipeline that ships the service create it, keyed on a health endpoint, and the coverage gap closes for good:

curl -sS -X POST https://undownable.com/api/v1/monitors \
  -H "Authorization: Bearer $UNDOWNABLE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "team": "acme",
    "name": "checkout-api",
    "tag": "production",
    "type": "json",
    "target": "https://checkout.example.com/health",
    "interval_seconds": 60,
    "config": {"json_path": "status", "json_expected": "ok"}
  }'

Eight types are available (http, keyword, json, ssl, tcp, dns, ping, heartbeat). Heartbeat suits a job rather than a service: the response carries a ping_url your cron hits, and the monitor goes down when the pings stop.

Workflow: a weekly agent audit

Monitoring rots quietly. Monitors get paused for an afternoon and stay paused, new services land untagged and fall out of every filter, and nobody notices until the unwatched thing breaks. A scheduled agent run that reports the drift is a few lines:

curl -sS -H "Authorization: Bearer $UNDOWNABLE_TOKEN" \
  https://undownable.com/api/v1/monitors \
  | jq '.data[] | select(.tag == null or .paused) | {name, tag, paused, status, last_checked_at}'

Every monitor payload carries tag, paused, status, in_maintenance, last_checked_at, and its config key names, so the audit needs no state of its own. A conversational agent answers the same question with list-monitors, then offers to resume whatever should never have stayed paused.

Guardrails that make agent access safe

Handing write access to something that occasionally hallucinates is only reasonable if the blast radius is bounded. Four things bound it:

• Least-privilege abilities. Tokens are minted with a chosen set: user:read, teams:read, fleet-status:read, monitors:read, monitors:write, incidents:read, status-pages:read, status-pages:write, maintenance-windows:read, maintenance-windows:write, and mcp. A status board gets monitors:read; a deploy script gets maintenance-windows:write.
• Team pinning. Pin a token to one team at creation and it can never see the others. Unpinned tokens must name their team on every write, because inheriting whichever team someone last clicked in the dashboard is how a nightly script eventually points at the wrong systems.
• Errors that teach. A 422 names what to fix specifically: an unknown config key comes back with the valid keys for that monitor type, a bad interval lists the five accepted values and your plan minimum, a keyword monitor missing its keyword is told why that check would pass against an error page.
• Real limits. Both surfaces are rate limited per token (the MCP server at 60 requests a minute), and plan caps bound monitor count and check frequency, so a loop that goes wrong hits a ceiling instead of a bill. Policies are the dashboard's, so a token cannot exceed its owner's role.

A human approves the alert channels

Worth stating plainly, because it is a deliberate limit rather than a missing feature: an agent can create, retune, pause, and delete monitors, schedule maintenance, and publish status pages, but a human approves the alert channels. Wiring up email, ntfy, Telegram, Slack, Discord, or a webhook happens in the dashboard, so every destination an agent can send noise to is one a person chose. Delivery is exactly once per incident transition.

Where to start

Give an agent a token with monitors:read and incidents:read, pinned to one team, and ask what your uptime looked like last week: a five minute experiment with no way to break anything. If the answer is useful, widen the token to monitors:write and let the deploy script own its windows next.