Before you start
Connect the MCP server to Claude, Cursor, or any other assistant that supports MCP. You can then ask in plain language. The assistant picks the right tools, likealert_stats and escalation_stats, and totals your data for you.
Answers get sharper when your alerts carry 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:- Collects alert and page data for each source, team, and week.
- Inspects sample alerts from the noisiest sources.
- Looks for patterns, like status page alerts, alerts that flap, thresholds set too tight, and noise concentrated in a few places.
- Recommends specific changes, each with its evidence and an estimate of the pages and responder time it would save.
- Produces a report you can share.
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 so they’re dropped. If you still want a record of them, give them a lower priority 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 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 to hold back pages while you deploy or migrate.