Occupational medicine and neuroscience research converges: cognitive capacities between 2am and 6am are significantly reduced — extended reaction time, diminished complex reasoning, reduced working memory, tendency to fixate on incorrect solutions. An incident managed at 3am by an engineer woken abruptly is statistically more likely to produce a human error, a suboptimal decision, or an unnecessary escalation than an identical incident managed during the day.

The infrastructure industry measures MTTR — Mean Time to Repair. It does not measure the correlation between incident trigger time and resolution quality. It does not measure the number of incidents that escalate because a 3am decision worsened the initial problem. It does not measure the cost of nocturnal human errors. This cost is real. It is simply invisible in operational performance dashboards.

Stage 1 — Active compensation: the engineer compensates for fatigue through conscious effort. They are more careful, double-check, document better to offset the memory gaps they are starting to feel. This stage is invisible externally — they will overperform on indicators.

Stage 2 — Progressive disengagement: compensation becomes too costly. The engineer begins doing the bare minimum — not out of laziness, but to preserve remaining resources. Work quality degrades slightly. They begin avoiding complex tasks.

Stage 3 — Collapse: accumulation reaches a threshold. The engineer stops — sick leave, resignation, or the most dangerous scenario for the organisation — they stay but are no longer really there.

On-call is not the sole cause of burnout in infrastructure. But it is a powerful amplifier of all other causes — excessive workload, lack of recognition, loss of meaning, organisational conflicts. An already pressured engineer who accumulates on-call nights accelerates their progression to stage 3. On-call frequency is as reliable a burnout risk indicator as any workplace wellbeing questionnaire.

— On-call frequency per engineer per month (number of nights and weekends)
— Number of nocturnal alerts received per engineer (not just incidents handled)
— Average recovery time after an on-call night (hours before returning to normal work)
— Rotation rate on on-call positions (high rate is an early burnout signal)
— Correlation between night-managed incidents and human errors documented in post-mortems

None of these metrics are standard in the sector. Some exist in the most mature organisations. The majority do not calculate them.

A heroic engineer absorbing an excessive on-call load makes the problem invisible to their manager. The system runs. Incidents are resolved. Metrics are good. The underlying structure — too few engineers, overly sensitive alerting, fragile architecture — is never questioned because individual heroism compensates for its flaws. Until the engineer stops.

SRE culture introduced the blameless post-mortem — incident analysis without designating an individual culprit, seeking systemic causes. This is a real advance. But the blameless post-mortem addresses technical incidents. It does not address human incidents — burnout, the departure of an expert, the error of an exhausted engineer. These events are rarely treated with the same analytical rigour as server faults.

The most mature SRE organisations — certain teams at Google, Netflix, Stripe — have begun treating on-call load as an operational risk on a par with technical debt. They set maximum on-call thresholds per engineer, make rotation mandatory, measure nocturnal alert volume and reduce it as they would pay down technical debt. This is not goodwill — it is risk management.

Define and respect a maximum number of on-call nights per engineer per month. This threshold is not a preference — it is an operational limit, like a server's maximum load limit. If the team cannot respect this threshold, it is an understaffing signal that should trigger recruitment or a reduction of the on-call scope.

The majority of nocturnal alerts are either false positives or alerts for events that do not require immediate intervention. Reducing this volume is engineering work — revising alert thresholds, removing alerts that never trigger action, consolidating redundant alerts. This work is systematically deprioritised. It should be treated as technical debt to be actively paid down.

On-call has a real physical and cognitive cost. It must be financially compensated at a level that reflects this cost — not symbolically. It must also entitle the engineer to protected recovery time the following morning: an engineer woken at 3am cannot be in a meeting at 9am without performance degradation. This recovery is not a luxury — it is the recharging of a critical operational resource.

The best response to excessive on-call is not organisational — it is architectural. Self-healing systems, resilient architectures, well-designed automatic failovers reduce the number of incidents requiring nocturnal human intervention. Investing in architectural resilience is the most direct investment in the health of on-call teams.

Companies with more than 50 employees produce an annual social report. Integrating on-call metrics into it — average number of nights per engineer, nocturnal alert volume, rotation rate on on-call positions — makes visible what is structurally invisible. This transparency creates compliance pressure that the absence of measurement does not allow.

The Syntec and digital sector collective agreements frame overtime, flat-rate day arrangements, and the right to disconnect. They do not specifically frame recurrent nocturnal on-call in critical production environments. A specific clause — maximum threshold, minimum compensation, guaranteed recovery time — in digital sector agreements is a measure within reach of social negotiation.

A manager evaluated on system availability but not on their team's on-call load has an incentive to understaff teams and overload individuals. Adding on-call load as a management evaluation criterion — at the same level as technical indicators — changes the structural incentives of middle management.