> ## Documentation Index
> Fetch the complete documentation index at: https://docs.incident.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Find alert noise and pager load with the MCP server

> Find the alerts that wake people up for nothing, and fix them, by asking your AI assistant.

The [incident.io MCP server](/ai/remote-mcp) lets your AI assistant answer questions about your alerts and pages: which sources are noisiest, how many alerts ever become incidents, and when people get paged. Use it to find the alerts worth tuning, and the responders carrying the most on-call load.

## Before you start

[Connect the MCP server](/ai/remote-mcp#setup) to Claude, Cursor, or any other assistant that supports MCP. You can then ask in plain language. The assistant picks the right tools, like `alert_stats` and `escalation_stats`, and totals your data for you.

Answers get sharper when your alerts carry [attributes](/on-call/alert-attributes) like team and service, because you can then break noise down by who owns it, not just by where it came from.

## Ask about your alerts

Start broad, then narrow down. For example:

* **"Which alert sources sent the most alerts last month, and how many of them became incidents?"** A source that sends many alerts and almost no incidents is the most likely noise. Third-party status pages often come out on top.
* **"Break that down by team and service."** Noise is often concentrated in a few places, even when it comes from one monitoring tool.
* **"Show me a sample of the alerts from that source that didn't become incidents."** Looking at real alerts is how you find which monitors to tune, rather than whole sources.
* **"How much responder time did the incidents from each source cost?"** Each answer includes a workload breakdown, split into working hours, late evening, and overnight, so you can see what noise is costing people.

## Ask about pages

For example:

* **"How many pages were there last month, and when?"** Pages are grouped into working hours, late evening, and overnight, in UTC.
* **"Who got paged the most?"** This shows on-call load by person, so you can spot someone who's carrying more than their share.
* **"What's the acknowledgement rate for each escalation path?"** The share of pages that someone acknowledged, rather than letting them expire. A low rate often means people have learned to ignore that path.
* **"Which paths have the most cancelled pages?"** A page is cancelled automatically when its alert resolves, or is attached to an incident, before anyone acknowledges it. Lots of cancellations can mean alerts that fire and clear within minutes.

## Run a full alert noise analysis

For a thorough review, ask **"Analyze our alert noise and recommend tuning improvements."** The assistant uses a built-in alert noise playbook, which works through the analysis in stages:

1. Collects alert and page data for each source, team, and week.
2. Inspects sample alerts from the noisiest sources.
3. Looks for patterns, like status page alerts, alerts that flap, thresholds set too tight, and noise concentrated in a few places.
4. Recommends specific changes, each with its evidence and an estimate of the pages and responder time it would save.
5. Produces a report you can share.

There are also playbooks for an on-call burden review, a team health check, and a full operational review. See [Use playbooks for structured analysis](/ai/remote-mcp#use-playbooks-for-structured-analysis).

## Fix what you find

Most noise comes down to a handful of causes, each with a fix in incident.io:

* **Alerts nobody can act on**, like a third-party status page: if you never need them, [filter them out at the source](/alerts/alert-sources#filter-incoming-alerts) so they're dropped. If you still want a record of them, give them a lower [priority](/alerts/priority-routing) instead, so your escalation paths can treat them as low urgency.
* **Alerts that flap**: fix the threshold in your monitoring tool, and make sure repeat events share a [deduplication key](/alerts/deduplication) so they update one alert instead of creating several.
* **Everything at the same urgency**: set priorities from alert attributes, so only the alerts that need someone now wake them up.
* **Noise during planned work**: use a [maintenance window](/alerts/maintenance-windows) to hold back pages while you deploy or migrate.

After a change, ask the same questions again a few weeks later to check it worked. If you'd rather see the trends in a dashboard, [Alert insights](/alerts/alert-insights) tracks alert volume and acceptance, and [Pager load](/insights/core-dashboards#pager-load) tracks who gets paged and when.