Monitoring is not on call

Many teams that say they have on call actually have monitoring. Dashboards exist, alerts fire, messages arrive in a shared channel. What is missing is a person who must respond, has the access to act and knows who can make the business decision when the fix has a cost. Monitoring produces signals; on call is the arrangement that turns a signal into an action.

Three questions per incident

We trace the path with three questions. Who is alerted? Not a channel or an inbox, a named person on a rota, with a second person if the first does not acknowledge. Who can act? The person alerted needs production access, a runbook and permission to use both at three in the morning. Who decides? Some fixes have a business cost, such as taking a feature offline, and someone with the authority to accept that cost must be reachable.

Walk a recent incident through those questions and the break is usually obvious. The alert went to an inbox nobody owns. The engineer who saw it had no access to the database. The decision to roll back waited for an executive who was on a plane.

Fewer alerts, with owners

An alert is worth keeping only if a person can act on it. We sort the current alerts into those that point to user-facing harm, those that predict it, and those that nobody has acted on in months. The third group goes, or becomes a dashboard. Every remaining alert gets an owner, a severity and a link to the runbook step it starts.

Cutting alerts feels risky to teams that have been burned before, so we cut in writing: each removed alert is listed with the reason, and any of them can come back with an owner attached. A shorter list that people trust beats a long one they have learned to ignore.

Writing the path down

The incident path ends up on one page per severity: who is alerted, who acts, who decides, how they talk to each other and when customers are told. Authority to act is agreed before the incident, not negotiated during it. Patching, backups and changes get the same treatment, because most incidents start with one of them.

Testing it

A path that has never been walked is a theory. We run it once outside working hours, with a staged alert and a real person on the rota, and we record how long each handover took. The gaps that show up are usually practical: an expired password, a phone on silent, a runbook that assumes a tool nobody has installed. Fixing those is the point of the exercise.

Once the path works, monitoring finally has somewhere to send its signals, and the team gets its nights back.