Anderson SoResume

Writing ·

Alert fatigue is not a tooling problem

If your team has stopped reading the alerts, a better alerting tool will not save you.

Infographic: alert fatigue is not a tooling problem. You alert on what is interesting, not actionable; if nobody acts it is a metric, not an alert; every alert names an owner and an action; severity maps to a response, not a feeling; the fix is deleting alerts, not tuning them.

What teams usually try first:

  • Migrate to a new monitoring platform
  • Add more dashboards
  • Tune thresholds
  • Add a second on-call tier

Same noise, nicer interface.

The actual cause is simpler and less comfortable:

  • Alerts were created for things that are interesting, not things that are actionable
  • If nobody has to do anything when it fires, that’s a metric, not an alert
  • Every surviving alert should name an owner and an action
  • Severity should map to a response, not to a feeling
  • The fix is deleting alerts, and nobody gets promoted for deleting things

Noise isn’t a tooling problem. It’s a decision nobody wanted to make.

The question isn’t “what should we alert on?”

The question is “what will we actually do at 3am when this fires?”

If there’s no answer, it shouldn’t page anyone.

How many of your alerts would survive that test?

  • #SRE
  • #DevOps
  • #Observability
  • #OnCall
  • #Monitoring
  • #IncidentManagement
  • #PlatformEngineering
  • #CloudComputing
  • #AWS
  • #EngineeringLeadership
  • #Reliability
  • #AIOps

First posted on LinkedIn. Join the conversation there (opens in a new tab)

All writing