Stackbook Logo
operations

On-Call Health Framework

Intent

Keep on-call rotations sustainable by measuring load, limiting toil and acting on signals of responder burnout.

Problem

Noisy pages, thin rotations and unclear escalation wear engineers down, causing attrition and slower incident response. Leaders rarely see the cost because nobody measures interrupts, sleep disruption or the fairness of the rota.

Forces

    Solution

    On-Call Health Framework

    On-call is a cost paid by people. This framework makes that cost measurable and keeps it within limits so reliability does not depend on exhausted individuals.

    How it works

    Every page is recorded with timestamp, service, whether it was actionable and how long it took to resolve. Monthly reviews aggregate this data per team and per person, compare it to agreed thresholds and decide on action. Alerts that fire repeatedly without action are tuned, automated or removed, and sustained overload triggers a staffing or priority discussion.

    Health is as much about predictability as about volume. Engineers can tolerate an occasional bad night if they know the rota well in advance, can swap shifts easily and receive visible recognition afterwards. Conversely, a low page count with unclear ownership and no escalation path can feel worse than a busier but well supported rotation. Combine quantitative thresholds with a short quarterly survey so that the numbers and the lived experience are reviewed together, and so that managers hear about problems the dashboards cannot show.

    Implementation steps

    1. Define healthy limits: pages per shift, after-hours pages per week, and maximum consecutive shifts.
    2. Set a minimum rotation size so each person is on call no more than one week in six.
    3. Export paging data into a dashboard grouped by service and responder.
    4. Hold a short weekly handoff to review last week's pages and open follow-ups.
    5. Classify every page as actionable, informational or false, and fix the latter two.
    6. Provide shadow shifts, runbooks and a clear escalation path before new people join.
    7. Define compensation, rest days after bad nights and the right to swap shifts.

    Pitfalls

    • Treating the pager as free, so alerts are added without removal.
    • Concentrating knowledge in two senior people who carry most of the load.
    • Measuring page count but ignoring night-time impact.
    • No escalation path, so juniors struggle alone.
    • Handing the pager to a team without giving them authority to fix root causes.

    Metrics to watch

    • Pages per shift and after-hours pages per week.
    • Percentage of pages that were actionable.
    • Time to acknowledge and time to resolve.
    • Rotation size and distribution of load by person.
    • Responder survey score and on-call related attrition.

    Example health thresholds

    rotation:
      min_size: 6
      shift_length_days: 7
      follow_the_sun: false
    thresholds:
      pages_per_shift:
        target: 2
        warn: 5
        escalate: 10
      after_hours_pages_per_week:
        target: 1
        escalate: 4
      actionable_ratio_min: 0.8
    actions_on_breach:
      warn: "Review top three noisy alerts in weekly meeting"
      escalate: "Freeze feature work for the service until load is below warn"
    support:
      shadow_shifts_required: 2
      recovery_day_after_night_page: true
    

    Key takeaways

    • Every page should need a human and a new decision.
    • Rotation size is the biggest lever on sustainability.
    • Measure the burden and act on it, or it will manifest as attrition.
    • Compensation and recovery time are part of reliability engineering.

    ✓ When to Use

    • •Engineers carry pagers for services they build
    • •Page volume or after-hours interruptions are rising
    • •Attrition or morale issues are linked to operational load
    • •You are creating a new rotation or splitting an existing one

    ✗ When Not to Use

    • •Teams with no production responsibility
    • •Services supported by a dedicated follow-the-sun operations team
    • •As a substitute for fixing the underlying reliability issues

    Pros

    • +Reduces burnout and turnover
    • +Improves alert quality and incident response
    • +Makes operational load visible to management
    • +Distributes knowledge across more engineers

    Cons

    • −Needs sustained measurement and review effort
    • −Compensation and time-off policies add cost
    • −Small teams may not reach a healthy rotation size
    • −Metrics can be gamed by silencing alerts

    Cost Profile

    Infrastructure

    Operational

    Cognitive

    Failure Modes

      Alternatives

        Related Patterns

          Competency Domains

          reliability opseconomics evolutionrequirements constraints