Module on_call_metrics 

On-Call, Capacity, and Operational Load Metrics

On-call load often concentrates on a small number of experienced people who can resolve incidents fastest — the same pattern this book warns against for code review load and knowledge concentration elsewhere, applied here to operational burden. A team-wide average page frequency can hide this concentration entirely; measuring the busiest individual’s share, and how often any one person is on call relative to a sustainable limit, surfaces the burnout and bus-factor risk a simple average cannot.

Formula

Paging concentration (%)      = busiest engineer's pages / total pages × 100
On-call frequency ratio        = weeks on call / total weeks
Exceeds sustainable frequency   when on-call frequency ratio > max ratio
                                  (commonly 0.25, "no more than one week in four")

Why it matters

Rebalancing rotations deliberately, once concentration appears, depends on actually measuring individual-level page distribution rather than only a team-wide average — the average can look entirely reasonable while two or three people effectively carry the rotation due to skill gaps or availability constraints. Aggregate this data at the team level to inform staffing and hiring decisions; never use individual page-response metrics to evaluate a specific engineer’s performance.

Example

use software_engineering::on_call_metrics::{
    paging_concentration_percent, on_call_frequency_ratio,
    exceeds_sustainable_on_call_frequency,
};

// Of 40 pages across the team last quarter, the busiest engineer took 22.
let concentration = paging_concentration_percent(22.0, 40.0).unwrap();
assert!((concentration - 55.0).abs() < 1e-9);

// That same engineer was on call 6 of the last 12 weeks: one week in two,
// well past the "no more than one week in four or five" guideline.
let ratio = on_call_frequency_ratio(6.0, 12.0).unwrap();
assert_eq!(ratio, 0.5);
assert_eq!(exceeds_sustainable_on_call_frequency(6.0, 12.0, 0.25), Some(true));

Pitfalls

• Reporting only a team-wide average page frequency — hides severe individual concentration that drives both burnout and bus-factor risk.
• Treating a nominally adequate rotation roster as sufficient without checking whether it effectively relies on only two or three people due to skill gaps or availability constraints.
• Measuring only active incident time, ignoring the psychological cost of being on call even during a shift with zero pages.
• Using individual page-response metrics to evaluate a specific engineer — the goal is sustainable staffing and system design, never individual scorekeeping.

Sources

• Chapter 6.3, On-call, capacity, and operational load metrics.

Topic doc: software-engineering-metrics/locales/en-001/chapters/06-03-on-call-capacity-and-operational-load-metrics.md

Functions

exceeds_sustainable_on_call_frequency

Whether an engineer’s on-call frequency exceeds a given sustainable maximum, such as the chapter’s example of “no more than one week in four or five” (a max_ratio of 0.25 or 0.20).

on_call_frequency_ratio

On-call frequency ratio: the fraction of weeks an engineer spent on call.

paging_concentration_percent

Paging concentration: how much of the team’s total paging load fell on the single busiest on-call engineer.