Alert fatigue is a UX problem, not a discipline problem

Every alerting tool I've used sells itself on coverage: more integrations, more metrics, more channels. None of them sell themselves on restraint. That's backwards, because the thing that actually burns out an on-call engineer isn't missing an alert — it's drowning in ones that didn't need a human.

The dashboard was never the problem

Grafana panels and Alertmanager rules are fine at the source. The failure happens downstream, in the inbox: a single unsorted stream where a disk-usage warning from a staging box sits next to a checkout-service 5xx spike, both formatted identically, both demanding the same amount of attention. Nothing in that feed tells you which one matters more than a glance would.

That's a UX problem, not a monitoring problem. Teams don't get worse at triage over time — the interface just never helped them triage in the first place.

Grouping and severity aren't nice-to-haves

Two changes fix most of this without touching a single alerting rule. First, group by source — every alert from the same client or service collapses into one thread instead of ten separate pings. Second, make severity visually load-bearing: a critical alert should not look like an info log with a different label, it should be unmistakable at a thumbnail size.

I built Blare around exactly those two ideas. It doesn't replace Alertmanager or Grafana — it sits on top of whatever you already have and turns the firehose into something closer to a triage queue: grouped by client, color-coded by severity, and pushed to your phone as a real notification instead of another line in an email digest.

What this actually buys you

The measurable outcome isn't fewer alerts — it's fewer alerts that require a decision before you can tell whether they matter. When the noisy ones are visually quiet and the important ones are visually loud, on-call stops being a vigilance exercise and starts being what it should be: respond fast when it's real, ignore fast when it isn't.