PagerDuty for uptime monitoring
PagerDuty's official MCP server exposes incidents, services, schedules, and orchestrations across 64 tools, read-only by default. For uptime monitoring it is our fourth pick of four, and that ranking is fair: PagerDuty tells you what is actively paging and who is responding, but it does not measure whether a service is up. It reacts to outages rather than detecting them.
Where it still earns a slot is the response side of monitoring. Once a check fails somewhere and an incident opens, PagerDuty is where an agent sees the alert fire, the schedule it routed to, and the responder on it. For the actual health probing, though, look to the monitoring siblings.
How PagerDuty fits
The tools that apply here read incident and alert state. list_incidents shows what is currently paging, and list_alerts_from_incident with get_alert_from_incident reveal the alerts behind an incident so an agent can see what tripped. The change-event tools, list_change_events, get_change_event, list_service_change_events, and list_incident_change_events, help correlate a downtime window with a recent deploy. Alert grouping (list_alert_grouping_settings, get_alert_grouping_setting, and the create, update, and delete variants) controls how flapping alerts collapse into a single incident so the picture stays readable during an outage.
The limit is the whole reason for the rank: PagerDuty runs no synthetic checks, no uptime probes, no latency or availability metrics. It learns a service is down only when something else tells it. Better Stack is the stronger pick for status-and-uptime monitoring with its own heartbeat and HTTP checks, Datadog for full observability with metrics, synthetics, and traces, and Sentry for error-tracking that catches failures users hit. Use PagerDuty as the layer that tells an agent what is paging and who owns it, paired with one of those for the monitoring itself.
Tools you would use
| Tool | What it does |
|---|---|
| list_alert_grouping_settings | Lists alert grouping settings. |
| get_alert_grouping_setting | Gets a single alert grouping setting. |
| create_alert_grouping_setting | Creates an alert grouping setting. |
| update_alert_grouping_setting | Updates an alert grouping setting. |
| delete_alert_grouping_setting | Deletes an alert grouping setting. |
| list_alerts_from_incident | Lists the alerts associated with an incident. |
| get_alert_from_incident | Gets a single alert from an incident. |
| list_change_events | Lists change events. |
| get_change_event | Gets a single change event. |
| list_service_change_events | Lists change events for a service. |
FAQ
- Does the PagerDuty MCP server check whether my services are up?
- No. It has no uptime probes, synthetic checks, or availability metrics. It surfaces incidents and alerts that other systems raise, via list_incidents and list_alerts_from_incident. For actual uptime checks, Better Stack or Datadog fits better.
- Then why use PagerDuty for uptime monitoring at all?
- For the response side. When a check elsewhere fails and pages, PagerDuty shows the firing alert, the on-call schedule, and the incident state, so an agent can see who is responding and correlate the outage with recent change events.