Why People Shouldn't Be
Your Alerting System

When teams rely on people to notice failures, they build inconsistency into operations. Someone has to remember to check a dashboard, inspect a queue, open a report, or ask whether a job finished. That works only until the responsible person is busy, asleep, or unaware that the process mattered today.

Human alerting often looks reliable because it works on ordinary days. The same person checks the same report every morning. The same team lead notices when a job is quiet. The same support channel gets a quick answer because the right engineer happens to be online. That pattern can feel like a process, but it is really a habit.

Habits break when availability changes. The person who usually notices the issue may be in meetings, travelling, on leave, dealing with childcare, or focused on urgent project work. They may still technically be working, but not watching the thing the system depends on them watching.

Events change who is available

Large events expose the weakness of human alerting because they change attention across many people at once. A major football match can pull half a team away from their normal routines. Some people leave early to travel. Others are in a pub, at the stadium, or following updates while messages pile up. Even those still at their desks may be less likely to notice a quiet dashboard or an unusual gap in a scheduled process.

The same pattern appears around conferences, company off-sites, product launches, school holidays, transport disruption, severe weather, and public events. These are not edge cases. They are normal operating conditions for real teams. Availability is uneven, attention moves, and informal coverage becomes fragile exactly when coordination is harder.

This matters because failures do not wait for the convenient parts of the calendar. A reconciliation job can stall during a cup final. An import can start dropping records while several engineers are at an event. A customer-facing report can go stale over a bank holiday weekend. If detection depends on someone casually noticing, the system has no reliable answer to the question, "Who is actually watching right now?"

Human coverage is not the same as system coverage

Teams often compensate by saying that someone is usually around. But "usually" is not an alerting strategy. It does not define what should be checked, how often it should be checked, what counts as abnormal, who is notified, or what evidence should be available when the notification arrives.

Good alerting should survive changes in who is present. If a critical process stops making progress, the signal should not depend on the memory, attention, or personal routine of a specific person. It should come from the process itself, with enough context for whoever is available to understand the state of the work.

Human alerting also changes the emotional cost of incidents. People feel responsible for not seeing what the system never surfaced clearly. That is a design failure, not a personal failure.

Let people interpret, not patrol

Telemetry should move routine detection into the system. OpenTrace gives background work a way to report status and expose gaps in activity. People can then spend attention on interpretation and response instead of patrol.

That is the better split of responsibility. Software should notice missing progress, stalled phases, unexpected counts, late milestones, and silence where activity was expected. People should decide what it means, how serious it is, and what response is appropriate.

When football, events, holidays, or ordinary life change who is available, reliable telemetry keeps detection from depending on luck. The system should be able to raise its hand before a human happens to look in the right place.