Monitoring as code, and what changes when an AI agent can create the monitors

Monitors that live in version control are reviewable and reproducible. MCP takes the next step: an assistant that can read incidents, propose monitors and open a pull request — inside the permissions you give it.

Monitoring set up by hand has a familiar arc: someone creates thirty monitors in a UI, leaves the company, and two years later nobody knows which of them matter. Monitoring as code fixes the arc by treating monitors like any other configuration — defined in files, reviewed in pull requests, applied by CI, and reproducible in a new environment with one command.

What it looks like

Every serious monitoring product has an API; monitoring as code is mostly the discipline of using it. A definition per service, in the service's own repository, applied on deploy:

[
  { "name": "Checkout API", "type": "http", "target": "https://api.example.com/health",
    "interval_seconds": 30, "region_codes": ["us-east", "eu"],
    "config": { "assertions": [{ "type": "status", "equals": 200 }], "failure_threshold": 2 } },
  { "name": "Checkout journey", "type": "multi_step_api", "interval_seconds": 300,
    "config": { "steps": [ … ] } }
]

• Review — a change to a threshold or a region is a diff someone reads.
• Provenance — the monitor exists because a commit created it, and the commit says why.
• Environments — the same file, with a different base URL variable, monitors staging and production.
• Cleanup — delete the service, delete the file, the monitors go too.

Where an AI agent fits

The Model Context Protocol (MCP) gives an assistant — Claude, Cursor, a custom agent — a typed set of tools it can call against a product: list monitors, read an incident, create a monitor. With monitoring exposed over MCP, the workflows that used to need a person clicking through a UI become things you can ask for:

• "We just added /v2/orders. Add an HTTP monitor from three regions with a status assertion and the same destinations as the other order endpoints." — the agent reads the existing monitors, mirrors their configuration, and creates the new one, or writes it to the repo for review.
• "Why did checkout page at 02:14?" — the agent reads the incident, the failing execution, and the change events before it, and answers with the DNS change that preceded the failure.
• "Which monitors have no notification destination?" — a question that is a query, not a project.

The permissions question

The moment an agent can create and delete monitors, the question is the same as for any automation: what can it do, on whose authority, and how do you find out what it did? The useful pattern is the one already used for humans and API keys — the agent authenticates as itself over OAuth, receives only the scopes it needs, destructive actions require a person's approval, and every call is logged.