Before you start
Connect the MCP server to Claude, Cursor, or any other assistant that supports MCP. Once it’s connected, you just ask questions in plain language. The assistant works out which tools to call, likealert_stats and escalation_stats, and does the adding up for you.
You’ll get much more useful answers if your alerts carry attributes like team and service, because then you can break noise down by who owns it rather than just where it came from.
Ask about your alerts
It’s easiest to start broad and narrow down from there. Some questions that work well:- “Which alert sources sent the most alerts last month, and how many of them became incidents?” A source that sends lots of alerts and almost never produces an incident is your most likely noise. Third-party status pages often come out on top here.
- “Break that down by team and service.” Noise tends to be concentrated in a few places, even when it all comes from the same monitoring tool.
- “Show me a sample of the alerts from that source that didn’t become incidents.” Looking at real alerts is how you work out which specific monitors to tune, rather than writing off a whole source.
- “How much responder time did the incidents from each source cost?” Every answer includes a workload breakdown split into working hours, late evening, and overnight, so you can see what the noise is actually costing people.
Ask about pages
- “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 gives you on-call load by person, which makes it easy to spot someone carrying more than their share.
- “What’s the acknowledgement rate for each escalation path?” That’s the share of pages someone acknowledged rather than let expire. A low rate usually means people have learned to ignore that path.
- “Which paths have the most cancelled pages?” A page gets cancelled automatically if its alert resolves, or gets attached to an incident, before anyone acknowledges it. Lots of cancellations often points to alerts that fire and clear within a few minutes.
Run a full alert noise analysis
If you want the full picture rather than a few questions, ask “Analyze our alert noise and recommend tuning improvements.” The assistant picks up a built-in alert noise playbook and works through it 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
In our experience most noise comes down to a handful of causes, and each has 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 and they’ll be dropped. If you’d still like a record of them, give them a lower priority instead, so your escalation paths 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 rather than creating several.
- Everything at the same urgency. Set priorities from alert attributes, so only the alerts that genuinely need someone right now wake them up.
- Noise during planned work. Use a maintenance window to hold back pages while you’re deploying or migrating.