The Human Behind the Alert

As infrastructure has migrated to the cloud it has become increasingly abstracted and self-healing. Autoscaling groups restart failed instances. Health checks reroute traffic. Runbooks are codified into automation. Yet when something goes seriously wrong at 3 am on a Saturday, it is still a human being who wakes up, unlocks a phone, and starts diagnosing the problem.

The tech industry’s long-standing mantra of “move fast and break things” has spread well beyond Silicon Valley startups into every sector that depends on IT infrastructure. The problem is that this culture risks breaking the most important asset those organisations possess: the health and morale of the engineers who keep the systems running.

Why On-Call Culture Is a Systemic Problem

Scale brings complexity, and complexity brings unpredictability. An on-call engineer cannot know when the next page will arrive. The expectation of continuous availability—of being a “superhero” or “ninja” who is always ready to respond—creates sustained, chronic stress.

Some of the concrete consequences include:

• Cognitive degradation. A developer woken at 3 am to resolve an incident is unlikely to be productive, accurate, or safe the following day. Research in sleep science consistently shows that interrupted sleep can be more harmful than simply reduced sleep—though the on-call engineer often suffers both.
• Increased error risk. Fatigue reduces concentration. High-pressure, late-night incidents are exactly the conditions in which consequential mistakes happen. The 2017 GitLab database deletion incident—in which a tired engineer ran a destructive command on the wrong server—became a widely cited example of how human exhaustion amplifies operational risk.
• Staff attrition. Engineers with poor work-life balance leave. Replacing a departing employee carries significant costs in recruitment, onboarding, and lost institutional knowledge. Commonly cited estimates place replacement cost at a significant fraction of that employee’s annual salary, making wellbeing a hard business concern, not a soft one.

DevOps Extended with Empathy: Introducing HumanOps

DevOps already asks teams to break down silos between development and operations, to share responsibility for reliability, and to learn from failure without blame. HumanOps extends that thinking one step further: it asks organisations to treat engineer wellbeing as an operational metric with the same rigour applied to uptime or deployment frequency.

The term was coined by the team at Server Density (an infrastructure monitoring company) precisely because the business of sending alerts and waking people up made the human cost of on-call work impossible to ignore. The founding principle is straightforward:

Human health impacts business health.

Or, as Richard Branson has framed it in broader business terms: look after your people, and your customers and bottom line will benefit too.

Core HumanOps Principles

HumanOps is not a certification or a formal methodology—it is a set of guiding principles intended to shape how engineering organisations are run. The most important include:

• Human health is an operational concern. Wellbeing, rest, and sustainable pace are not HR soft topics—they directly affect system reliability.
• Alerts have a human cost. Every page that fires out of hours represents an interruption to someone’s rest, family time, or cognitive recovery. That cost should be tracked and minimised.
• Knowledge should not be siloed. When a critical fix can only be performed by one or two people, those individuals carry disproportionate on-call burden and become single points of failure for the organisation.
• Managers should share on-call rotation. Leadership that has never been paged at 4 am is poorly positioned to prioritise alert noise reduction or sustainable scheduling.
• Blameless postmortems matter. Creating a culture in which engineers can be honest about errors without fear of punishment is essential both for learning and for reducing the anxiety that makes on-call work more stressful than it needs to be.

Practical Steps for Engineering Teams

Abstract principles only help if they translate into concrete changes. Here are actionable practices teams can adopt:

1. Audit Your Alert Volume

Track the number of out-of-hours alerts per engineer per week. Any alert that fires repeatedly without triggering a fix is noise, not signal. Establish a regular process—sometimes called an “alert review”—to tune thresholds and eliminate pages that do not require immediate human action.

2. Define Escalation Policies Deliberately

Not every alert needs to wake a senior engineer immediately. Work with managers to map which failure modes genuinely require immediate human intervention, which can wait until business hours, and which should be handled through automated remediation. Document these policies explicitly.

3. Spread On-Call Load Equitably

Rotate on-call responsibilities across the team—including, where appropriate, managers and tech leads. Use scheduling tools to ensure no individual carries a disproportionate share of nights or weekends. Consider providing compensatory time off after a difficult on-call week.

4. Measure the Human Cost

Useful metrics to track include:

• Number of out-of-hours pages per engineer per month
• Mean time to resolve (MTTR) broken down by time of day
• Interruption cost in engineer-hours
• On-call hours per person over a rolling quarter

Surfacing these numbers in team retrospectives makes the human cost of reliability decisions visible and discussable.

5. Run Blameless Postmortems

After significant incidents, hold a structured review focused on systemic causes rather than individual blame. Document what happened, why, and what changes will prevent recurrence. Publish the postmortem internally so the whole organisation can learn from it.

6. Reduce Knowledge Silos

If only one or two people know how to resolve a class of incidents, invest in pairing, runbook documentation, and cross-training until at least three or four engineers are capable of handling those situations independently.

The Business Case Is Straightforward

Some engineering leaders still treat wellbeing as a “nice to have” that competes with delivery speed. The business case argues otherwise. Fatigued engineers make more mistakes, and mistakes in production are expensive. Burned-out engineers leave, and turnover is expensive. Alert-fatigued on-call teams respond more slowly, and slow incident response is expensive.

Investing in sustainable on-call practices—better tooling, smarter escalation, fairer rotation, and a culture that values rest—is not charity toward employees. It is sound operational engineering applied to the humans who run the systems.

Conclusion

DevOps has done an enormous amount to improve how software is built, deployed, and operated. But the movement has at times been so focused on automation, tooling, and process that it has overlooked the engineers at the centre of it all. HumanOps is a reminder that the most important assets in any technology organisation go home every night—and they need to sleep.

Recognising that engineers experience stress, that interrupted sleep has real cognitive consequences, and that sustainable working practices improve both business outcomes and human lives is not a radical idea. It is simply good engineering management applied to the whole system—people included.