Alert Triage for MSPs: Handling Multiple Clients Without Burning Out Your Team

One client's "critical" is another client's "check it in the morning." That's the specific version of alert fatigue MSPs deal with — one a single-client engineering team never has to think about. The same alert type, from the same monitoring rule, carries a completely different urgency depending on which environment it fired in.

A backup job failing on a client's e-commerce database at 2pm on a Friday is genuinely urgent. The same failure on a client's internal wiki, on a weekend, probably isn't. A generic alerting setup that treats every failure the same way either pages the on-call tech for things that can wait, or trains them to ignore pages entirely. The second failure mode is worse — it only shows up after the first one has happened enough times to teach the wrong lesson.

Why does a single severity scale break down across clients?

Because "critical" doesn't mean the same thing in every client's environment, and one scale can't capture that. Most monitoring tools ship with a single severity scale: info, warning, critical — the same baseline levels PagerDuty's own incident response documentation describes for a single environment. That works fine within one environment, where everyone agrees what "critical" means. Across a dozen client environments, SLAs differ, business hours differ, and tolerance for downtime differs.

A flat severity scale collapses all of that into one label. "Critical" ends up meaning both "wake someone up now" and "acceptable to look at Monday," depending on which client contract you check. That information isn't in the alert itself.

Building triage into the alert, not around it

The fix isn't a bigger severity scale. It's carrying client-specific context into the alert itself, so triage decisions are already encoded by the time the page is sent — not left for whoever's on-call to remember from a spreadsheet. This lines up with the broader principle in Google's SRE book chapter on monitoring distributed systems: an alert should carry the context a responder needs to act, not force them to go reconstruct it from a spreadsheet or a client list.

• Route by client SLA, not just alert type. A monitoring rule for the same failure condition should page differently depending on which client's environment it fired in. That can mean a different escalation policy, a different urgency level, sometimes a different responder entirely.
• Carry the client name and SLA tier in the page itself. An on-call tech who has to look up which client an alert belongs to has already lost time they didn't need to lose, time that should have gone straight into deciding how urgent it is.
• Use maintenance windows aggressively. A huge share of MSP alert noise is planned work — patching, migrations, scheduled reboots — that shouldn't page anyone at all. Suppressing alerts during a defined maintenance window for a specific client, without disabling monitoring for every other client, keeps the signal-to-noise ratio usable.
• Route by specialty when the team is split that way. Larger MSPs often separate network, systems, and application support into different rotations. An alert that carries enough context to route straight to the network on-call person, instead of a generalist who has to triage and forward it, saves a hop that adds real minutes during an outage.

What about a brand-new client who doesn't have an SLA tier set up yet?

Default to treating their alerts as urgent until someone deliberately says otherwise. A new client that hasn't been fully onboarded into the monitoring and paging setup is the one place a flat, high-urgency default is actually the safer choice, because there's no client-specific context yet to route on. Assigning every new client the same default escalation policy used for the most SLA-sensitive accounts, until someone reclassifies it, avoids the worse failure mode: a genuinely urgent alert from a new client getting silently deprioritized because nobody configured it yet. The cost of over-alerting for a few weeks during onboarding is small. The cost of a missed alert because a client fell through a configuration gap is not.

Webhooks make client-specific routing practical

Per-client alert routing is much easier when the monitoring tool and the paging tool talk over a plain webhook. The payload can carry through whatever client-identifying fields the monitoring rule already knows about. PingParrot accepts a webhook payload from any monitoring source and can route based on custom fields in that payload, including a client identifier. That routing sends the alert into different escalation policies automatically, so the "which client, how urgent" decision happens at alert time — not manually, every time someone picks up a page.

The real cost of getting this wrong

Alert fatigue at an MSP doesn't just cost the on-call tech sleep. It directly threatens the thing MSPs are selling, which is reliable response. A tech who's been paged for a dozen low-priority failures this month responds slightly slower to the one alert that's actually urgent. Their instinct has been trained by the noise, whether they notice it happening or not.

Alert fatigue's cost shows up in client relationships too, not just internally. A client who finds out their "critical" outage sat in the same queue as a dozen unrelated low-priority pings from other accounts is not going to be reassured by an explanation about alert volume — from where they sit, the MSP just looked slow. Getting triage right isn't a nice-to-have workflow improvement; for an MSP, it's close to the core product.