Monitoring isn’t about alerts. It’s about sleep.

Monitoring is often sold like a fireworks display: louder alerts, more dashboards, bigger numbers. But the real metric is much simpler. Do you get to sleep?

If your “monitoring” strategy is basically “wake a human up until the problem goes away”, you don’t have monitoring. You have a very expensive, slightly sweaty alarm clock.

Server racks: quiet, reliable and ideally not your reason for being awake at 3am. — The dream: the servers do their job and you do not become nocturnal.

Most monitoring setups start with good intentions and end as a sort of digital kettle drum. At first it’s one sensible alert. Then it’s fifteen. Then it’s “the CPU is at 71%” which, frankly, is the computing equivalent of saying “the toaster looks a bit stressed today”.

The problem is not that alerts exist. The problem is that we treat them like the product. A monitoring tool that only shouts is basically a smoke alarm that can’t point at the kitchen. It’s technically correct, but still quite rude.

The actual purpose of monitoring

Monitoring should do three things, in roughly this order:

Stop surprises: see issues coming before they become outages.
Reduce disruption: fewer wake-ups, fewer “all hands”, fewer Slack funerals.
Speed up fixes: when something breaks, you already know what, where and when.

If your alerts require a human to interpret them like ancient runes, they’re not alerts. They’re vague threats.

Why alert noise destroys sleep (and judgement)

When everything is “urgent”, nothing is. Your brain learns to ignore the beeps, which is fantastic until the one time it’s a real incident and you’ve mentally categorised it as “another liar”.

Also, being woken up at 3am turns perfectly reasonable adults into creatures who will confidently restart production services while half-asleep, then only remember doing it when they see their own commit history in the morning.

A dashboard showing trends and signals: what you want to see before it becomes an alert storm. — Dashboards are useful when they show trends, not when they become wall art.

Good alerts behave like a competent receptionist

A competent receptionist doesn’t ring you because somebody walked past the building. They ring you when:

something is genuinely on fire,
it’s your job to deal with it and
they already know which room is on fire.

That’s the standard. If an alert can’t tell you what’s wrong and what to do next, it belongs in a “heads up” channel, not in the “wake a human” category.

A simple sleep-first alert policy

Here’s a policy that works remarkably well, because it’s unglamorous and therefore correct:

Page only for customer impact (or imminent customer impact)
Everything else becomes a ticket (or an email for the morning)
Every alert must name an owner, or it gets demoted until it does.

You can still keep the signal. You just stop treating the human nervous system as infinite free compute.

An alarm clock: a reminder that waking humans should be a last resort. — “Just one more alert.” Famous last words.

What you should measure instead of “number of alerts”

If you want a grown-up monitoring programme, measure outcomes:

Time-to-detect (how quickly you notice something’s wrong)
Time-to-triage (how quickly you know what the problem is)
Time-to-recover (how quickly the service returns)
False positives per week (how often you cried wolf)
Pages per on-call shift (how often you ruined someone’s evening)

The goal isn’t “zero alerts”. The goal is trustworthy alerts. Ones you act on without rolling your eyes, sighing, or negotiating with the universe.

Final thought

Good monitoring is quiet. It’s boring. It’s the sort of boring that lets you go for a pint without keeping one eye on Grafana, and sleep without your phone charging on your pillow like a tiny rectangular menace.

If your monitoring doesn’t improve your sleep, it isn’t finished yet.