How to Reduce MTTR Without Adding More Alerts

You have too many alerts. You know you do. The 3am page for a queue length spike that had already resolved by the time you woke up. The dashboard with 47 red squares that mostly do not matter. The Slack channel where the alerts scroll faster than anyone reads them.

The instinct is to add more nuance: better thresholds, more sophisticated dashboards, a second on-call rotation for the "less critical" pages. That is the wrong move. Here is the counterintuitive one.

Why does adding alerts make MTTR worse?

Because human attention has a fixed budget, and every alert consumes some of it. When the budget is exhausted, the on-call engineer starts ignoring pages by default, then getting more selective about which ones to check first, then delaying the ack while they debug the "obviously false" alarms in their head before opening the dashboard.

The measurable effect: teams with more than 8 pages per on-call week have ack times that are 2 to 4 minutes longer than teams with 3 or fewer pages per week. Two minutes at the start of an incident is more valuable than 20 minutes at the end, because the blast radius is still growing.

Add another alert, and the ack lag on every alert grows, including the ones you needed to fire in the first place.

Which alerts should you cut first?

Apply a four-question test to every alert that fired in the last 90 days.

1. Did it correspond to a customer-visible symptom, or only to an internal metric?
2. Did the on-call take an action they would not have taken without the page?
3. Did that action need to happen in the middle of the night, or could it have waited until 9am?
4. Was the alert fired at the right threshold, or did it fire before the customer would have noticed?

• If the answer to (1) is no, the alert is monitoring a cause without impact. Convert it to a Slack channel or a dashboard, not a page.
• If the answer to (2) is no, the alert is informational. Downgrade to a ticket or a daily digest.
• If the answer to (3) is no, the alert should route to business-hours channels, not the pager.
• If the answer to (4) is "before," raise the threshold or add a duration gate (must be true for 5 consecutive minutes, for example).

Run this once and you will typically cut 40 to 60% of your page volume. The team you thought would be angry ("we might miss something!") will thank you within a week.

What does symptom-based alerting look like?

Alert on what your customer feels, not what your system feels internally.

The rule of thumb: a symptom-based alert fires when a customer would notice, and only then. A cause-based alert fires when something changed in the system, whether or not the customer noticed. The former is what you page on; the latter is what you dashboard.

Cause-based signals are still valuable. They are diagnostic aids for the responder once the symptom alert has fired. They are not paging conditions.

Where does the recovered attention actually go?

Cutting alerts is only half the play. The other half is investing the recovered attention in the response process. In order of leverage:

• Auto-declare from monitors. Every symptom alert should automatically create an incident channel, assign an initial severity, page the on-call, and post the alert context. Removing the manual declaration step cuts 5 to 12 minutes off average SEV2 duration.
• Fixed roles by rotation. The primary on-call is the commander by default; the secondary is the scribe. No debate at declaration.
• Structured status intervals. A 10-minute cadence with a fixed template. No composing prose from scratch.
• Timeline as automation output. Alerts, decisions, and status changes land on the timeline automatically. The scribe pins Slack messages to add narrative; they do not transcribe.

Each of these removes a manual coordination step that was previously eating the on-call's now-recovered attention.

What is the right MTTR target?

For a mid-size B2B SaaS with mature response practices, roughly:

• SEV1: 45 to 90 minutes from declare to resolution
• SEV2: 30 to 60 minutes
• SEV3: 4 to 24 hours

If your team is above these ranges, the fix is almost never "make engineers debug faster." It is one of: alerts fired too late, declaration lagged the alert by 5+ minutes, coordination in the first 10 minutes was chaotic, or the incident was carrying a scope creep problem that should have been split.

Measure MTTR by segment (detect, ack, declare, diagnose, repair, confirm) and the weakest segment will tell you where to invest.

How do you keep alert volume from growing back?

Alert volume grows back because every incident produces someone asking "how do we alert on this next time?" The answer is often correct in principle but wrong in practice: you add an alert for a specific symptom, then never revisit it, and it accumulates.

Two disciplines that prevent regrowth:

• Alert budget per service. Each service has a maximum number of paging alerts (typically 3 to 8). Adding a new alert requires removing or downgrading an existing one. Forces triage.
• Quarterly alert audit. Every alert that fired in the last 90 days gets reviewed against the four-question test. Alerts that fail get cut or downgraded. Non-firing alerts get reviewed for whether they still make sense.

Without one of these disciplines, alert volume drifts up 15 to 25% per quarter, and your MTTR wins evaporate.

The mistake to avoid

The mistake is confusing volume with coverage. Teams believe that more alerts mean more safety, so cutting them feels reckless. The opposite is true: fewer, better alerts fire more reliably, get acked faster, and produce faster incident declarations. The teams with the best MTTR are almost always the teams with the fewest active pages, because their signal-to-noise is high enough that the on-call trusts the pager. That trust is what actually moves the number.