Your monitoring problem might be too many alerts

I like dashboards. I just do not think they should be treated as a substitute for deciding what really matters.

If a team gets paged for every CPU spike, disk warning and transient network hiccup, eventually the alerts become background noise. You can have excellent telemetry and still be bad at noticing when customers are in trouble.

Grafana’s 2026 observability survey found alert fatigue was the biggest single obstacle respondents cited to faster incident response. That makes sense to me. The challenge is not collecting one more metric. It is deciding what should interrupt a person.

Start with the customer-facing symptom

For an online service, I want to know whether customers can log in, complete an order or use the core function. Those checks should be hard to ignore. I also want enough infrastructure and application data behind them to investigate quickly. But the existence of data does not mean it should all page somebody.

I would review the last month of alerts and ask a simple question about each one: what action did the team take? If the answer was “nothing” again and again, that is a candidate for tuning, grouping or removing. You are not making monitoring weaker. You are making the remaining signals more meaningful.