Service Catalog

Once you have more than ~10 monitors, configuring routing on each one stops scaling. The "Payments" team has 8 monitors? You want to say "Payments goes to the Payments on-call schedule with the Payments runbook" once, not eight times. Services let you do exactly that.

A service has:

• Tier — Tier 1 / 2 / 3 (badge on the list, included in alerts).
• Team — routes all alerts for member monitors to the team.
• On-call schedule — which rotation gets paged.
• Runbook URL — one click from the alert / incident to the playbook.
• Status page — optional public URL for the service.
• Alert channels — email / Slack / Teams / webhook config (overrides per-monitor settings).
• Paused toggle — mute every member monitor's alerts in one click.

When a service field is set, it wins over the same field on the individual monitor. So you can leave per-monitor team / on-call / runbook empty and let the service decide. If you ever do need a one-off override, the per-monitor fields still work for monitors that aren't in any service.

Available on Business and Enterprise plans (administrators always have access).

1. Go to /monitor/services.
2. Click + New Service.
3. Enter a name (e.g. "Payments API"); the slug is auto-generated.
4. Pick a tier, team, on-call schedule, runbook URL, status page subdomain — all optional.
5. Save. The service appears in the list immediately and gets its own detail page at /monitor/services/{slug}.

From the detail page you'll see a health rollup (Up / Degraded / Down counts across member monitors), the routing card (team, on-call, runbook, status page), the monitor list filtered to this service, and any open declared incidents linked to it.

Two ways:

1. One at a time, on the monitor create / edit form, pick the service from the Service dropdown under Organize.
2. Bulk, on the monitors list page, tick multiple monitors, choose a service from the bulk-action dropdown, click Assign service. Useful when you've just created a new service and need to retro-assign existing monitors.

Removing a monitor is the inverse — pick "— None —" from the dropdown. The monitor keeps all its own alert / team / runbook fields untouched, so removal doesn't drop coverage.

A status page can render services as components instead of (or in addition to) raw monitors. The service shows as a single row with rolled-up health: green if every member monitor is up, amber if any are degraded, red if any are down. Clicking through reveals the component monitors.

To add services to a status page:

1. Open the page in status page editor.
2. In the Services picker, tick the services you want to include.
3. Save. The footer of the public page also notes how many regions checks ran from (multi-region).

Cleaner stakeholder view than a long flat list of HTTP / SSL / DNS monitors — "Payments" reads better than "Payments API SSL / Payments API HTTP / Payments API DNS / Payments DB TCP".

When you open a declared incident, you can link it to specific services (and / or specific monitors). The service detail page shows recent declared incidents pinned to it, so on-call doesn't have to dig through the all-incidents list to figure out which incidents are about their service.

Linking an incident to a service also surfaces it on the service's status page row. Stakeholders see the incident comms (root cause, ETA, postmortem link) without you writing two updates.

Services are first-class on the REST API and MCP server.

• REST, GET /api/monitor/services lists; POST creates; PATCH /api/monitor/services?id=N updates; DELETE soft-deletes. Same auth as the monitors endpoints.
• MCP, list_services returns the catalog (tier, on-call, runbook, monitor count). Useful for asking Claude "which services are tier 1 and have anything down right now?".

See the REST API reference and the MCP guide for full request shapes.