The on-call load management decision record: why the alert volume threshold you set determines your burnout accumulation surface and your rotation size calibration failure mode

A 35-person developer productivity SaaS company built a continuous integration timing and flakiness analysis platform — identifying slow tests, tracking flaky test patterns, and surfacing test infrastructure bottlenecks for engineering teams. Their backend ran on AWS with 14 services, and their on-call rotation covered both infrastructure alerts and application-level issues. The rotation had been established when the backend team was 7 engineers: a weekly rotation with 7 participants, each on-call once every 7 weeks. The on-call policy specified who was eligible, how the schedule was set, and what the escalation chain was. It did not specify what volume of alerts was acceptable per shift.

The alert configuration had grown organically over two years of operating the product. After each incident, the post-incident review produced action items that included new or lowered-threshold alert rules to detect the same failure mode earlier. Over 24 months and approximately 40 significant incidents, the team had added 63 new alert rules and lowered the thresholds on 28 existing ones. Some of these rules were well-calibrated: they fired infrequently and almost always indicated a real problem. Others were poorly calibrated: they fired frequently on transient conditions — a 5-minute spike in database connection pool usage that resolved without intervention, an occasional spike in message queue depth during a large customer's scheduled batch run — and the on-call engineer had learned to wait 5 minutes and close the alert without action in most cases. The ratio of actionable to non-actionable pages had never been measured.

By the third year, the average number of pages per on-call shift was 11. The team measured this from PagerDuty incident counts. It did not look alarming on a chart — 11 incidents per week seemed like a moderately busy rotation. What the chart did not show was that the on-call engineer had learned, through 14 months of pattern recognition, that 8 of the 11 average pages required no action: the queue depth spike would resolve in 4 minutes, the connection pool alert would clear within a CFS quota period, the disk utilization alert was a false alarm because the alert threshold had never been updated after a storage migration increased the disk size. The 3 remaining pages per shift were genuine interventions — service degradations, data pipeline failures, or infrastructure anomalies that required diagnosis and action. The 8 noise pages were not resolved by tuning; they were managed by the on-call engineer who had memorized the patterns.

The quality-of-life impact was not visible in the incident metrics. An engineer who is paged at 2 AM and knows within 30 seconds that the page is noise still experiences the page — the phone rings, the adrenaline response activates, the sleep is broken, the 15 minutes needed to fully return to sleep are lost. Multiply by 8 non-actionable pages per week, a third of which historically fire between midnight and 6 AM, and the on-call engineer is losing approximately 2–3 hours of sleep per week to false alarms. Over a 7-week rotation cycle, each engineer experiences this once. Over two rotations — 14 weeks — the accumulated sleep disruption is 4–6 hours per rotation cycle. The engineers were not complaining formally; they were quietly updating their LinkedIn profiles.

Over 14 months, 3 of the 5 on-call-eligible engineers on the backend team left the company. Exit interviews cited various reasons: compensation, career growth, remote work flexibility. None specifically cited on-call load, because none had been asked about it. The effective rotation shrank from 7 to 4 without triggering any formal review. The 4 remaining engineers were now on a once-every-4-week rotation — nearly twice the previous frequency. The increased frequency meant each engineer was accumulating the 2–3 hours of weekly sleep disruption once every 4 weeks instead of once every 7 weeks. The rotation health had no dashboard. There was no metric that would have shown the connection between the attrition rate and the alert noise. The first formal review of on-call load occurred 6 weeks after the fourth engineer gave notice, when the engineering manager recognized that the rotation would collapse to 3 engineers and began an urgent postmortem. The postmortem identified that 68% of PagerDuty incidents in the prior 6 months had been closed without any action by the on-call engineer. Connect this failure to the alerting threshold decision record: the alert rules that produced the 68% non-actionable rate had each been created with sound intent — post-incident detection improvements, coverage of newly-identified failure modes — but had never been reviewed as a collective load after they were added; the alerting threshold decision record specifies the threshold for each individual rule, but the on-call load management decision record specifies the acceptable aggregate load from all rules combined and the governance process by which new rules are evaluated against that aggregate budget before they are added; both decisions are necessary, and neither can substitute for the other.

A 48-person payments platform built a real-time payment routing and reconciliation system for European fintechs — managing payment rail selection, fallback routing, and end-of-day reconciliation across 12 payment networks. Their on-call rotation covered the payment routing tier, the reconciliation pipeline, and the fraud signal aggregation service. The rotation had been established during the product's first year when the backend team had 10 engineers, 8 of whom were designated on-call eligible. An 8-person weekly rotation meant each engineer was on-call once every 8 weeks — a comfortable frequency that the engineering manager had deliberately designed to avoid the burnout dynamics he had observed at a previous company with a 4-person rotation.

The rotation plan was documented in the team wiki: the rotation schedule, the escalation chain, the on-call compensation policy, and the minimum viable roster size — documented as "8 engineers minimum to maintain once-every-8-weeks frequency." What the documentation did not specify was a review trigger: a condition that would cause someone to review the effective roster size and update the rotation plan. The on-call schedule in PagerDuty was maintained manually by the engineering manager, who updated it when engineers joined or left the on-call rotation. In practice, the update happened reactively: when a new engineer was ready for on-call duty (typically after 3–4 months on the team), they were added to the schedule. When an engineer left the company, they were removed from the schedule.

Over 14 months, 4 engineers left the payments backend team. Two went to competitor companies at higher compensation. One transferred to the company's internal platform engineering team. One went on a planned career break. Each departure was handled individually in PagerDuty: the engineer was removed from the schedule, and the schedule was re-balanced across the remaining participants. Nobody reviewed the cumulative effect on the rotation frequency after the fourth departure, because the frequency calculation was not automated and the minimum viable size of 8 was not monitored by any system alert.

After the fourth departure, the effective on-call roster was 4 engineers. Each engineer was now on-call once every 4 weeks — twice the original frequency. The change had accumulated over 14 months: each individual departure had felt manageable because it increased each engineer's frequency by a small amount (from once-every-8-weeks to once-every-7-weeks, then 6, then 5, then 4). No single step triggered a formal review. The cumulative effect had never been reviewed because no metric tracked it.

The compounding began to manifest when the first of the 4 remaining engineers went on 4 months of parental leave. The effective roster was now 3 engineers. A 3-person weekly rotation meant each engineer was on-call once every 3 weeks. For a payments platform with 24/7 availability requirements and a high-stakes on-call profile — payment routing failures during European business hours generate immediate customer escalations with contractual SLA implications — a once-every-3-week rotation at 3 total participants was not sustainable. The engineering manager escalated to the VP of Engineering. Two engineers from adjacent teams were temporarily added to the rotation, both of whom were unfamiliar with the payments routing tier and required an on-call buddy for their first 3 shifts. The temporary coverage ran for 11 weeks while two new backend engineers were onboarded. The original 3 permanent engineers each carried a once-every-3-week schedule for those 11 weeks while simultaneously onboarding the temporary rotators. Connect this failure to the on-call rotation compensation decision record: the compensation policy specified what each engineer received for on-call duty and did not adjust as the frequency doubled; engineers who had accepted the role at once-every-8-weeks were carrying once-every-4-weeks load at the same compensation structure; the compensation model and the load model are interdependent — a change in rotation size that doubles frequency without adjusting compensation is a de facto compensation reduction; the load management decision record must specify not only the minimum viable roster size but also the compensation review trigger that fires when the actual frequency deviates from the documented target by more than a defined threshold.

A 52-person observability platform built a distributed tracing, metrics aggregation, and log correlation SaaS for infrastructure teams at mid-size SaaS companies — a product whose users were themselves running on-call rotations and who were particularly attuned to the quality of the monitoring and alerting experience. Their engineering team ran a weekly on-call rotation with 9 engineers covering the platform's core ingestion pipeline, query tier, and storage backend. The rotation had been in place for 3 years and was operationally mature: runbooks for the 20 most common incident types, defined escalation paths, PagerDuty configured with appropriate routing policies.

The incident tracking system — their own product, used internally as a dogfooding exercise — recorded every PagerDuty alert as an incident. This was consistent with how the product worked: any alert that paged an on-call engineer created an incident record with a severity classification, a timestamp, and a resolution state. The engineering manager reviewed the incident count monthly as part of the operational health report. In the prior 12 months, the team had recorded 2,800 incidents — approximately 54 per week across the 9-person rotation, or 6 per on-call engineer per week.

The monthly report showed the incident count trending upward: from 38 per week in January to 62 per week by October. This was presented in staffing discussions as evidence that the engineering team's on-call load was increasing and that additional headcount was needed to maintain rotation sustainability. The staffing proposal was reviewed twice and deferred twice — the incident count increase was attributed to the product's rapid customer growth (more customers meant more ingestion volume meant more potential failure modes), and the proposed new headcount was deprioritized against product engineering hires that the revenue growth model required.

The incident count was accurate. What it did not capture was that a significant fraction of those incidents required no action from the on-call engineer. The team's internal retrospective had noted this anecdotally — "we get a lot of transient alerts that resolve themselves" — but had never quantified it. The incident tracking system had a resolution field where engineers documented what they did, but the resolution text was free-form and ranged from detailed post-incident analyses to "resolved — transient" with no further explanation. There was no structured actionability classification that could be queried programmatically.

In November, an engineer leaving the team ran a manual analysis of the prior 6 months of incident records as part of writing a transition document for her replacement. She read through 1,400 incident records and classified each as actionable (required investigation, diagnosis, or remediation), non-actionable (resolved as transient without action), or escalated (handed off to a secondary responder). Her findings: 74 incidents were escalated to a secondary responder (5%). 401 incidents were classified as actionable based on the resolution text — the engineer had run commands, modified configuration, deployed a fix, or written a post-incident analysis (29%). 925 incidents were resolved with a variant of "resolved — transient," "no action required," "false alarm — threshold too sensitive," or no meaningful resolution text (66%).

The 66% non-actionable rate meant that 1,848 of the 2,800 annual incidents were noise — alerts that fired, paged an engineer, and were closed without the engineer taking any action that improved system state. The 934 actionable incidents represented the genuine on-call load: approximately 18 genuine interventions per week across the rotation, or 2 per engineer per week — a sustainable load. The 1,848 noise pages had been adding approximately 35 false alarms per week to the rotation: not an unsustainable additional load in pure time terms (most false alarms were closed in under 3 minutes), but a persistent cognitive overhead that accumulated across the rotation and had been misdirecting the staffing justification for 18 months. Alert tuning work that had been deprioritized because the raw incident count was high would have reduced the noise from 35 pages per week to approximately 10 by tuning the 8 highest-volume non-actionable alert rules — 4 days of engineering work, estimated from the size of the rules. The tuning work had been on the backlog for 18 months at low priority because the backlog prioritization used incident count as the load signal, and high incident count was being used as an argument for more headcount rather than for alert tuning. Connect this failure to the incident response playbook decision record: the incident tracking system's free-form resolution field was the documentation model for 1,400 incident records and produced a dataset that required 40 hours of manual review to extract actionability signal from; the incident response playbook had not specified a structured classification requirement for incident resolution because the classification question had not been identified as a load measurement input at the time the playbook was written; the on-call load management decision record and the incident response playbook are interdependent — the load management decision identifies actionability classification as a required metric, which propagates into the incident resolution procedure as a structured field requirement, which makes the load metric available for ongoing review without requiring manual analysis of free-form text.

Structural properties set by the on-call load management decision

Three structural properties are determined when a team decides — or fails to explicitly decide — how to manage on-call load: what the alert volume budget determines about the burnout accumulation surface as noise builds up across multiple post-incident reviews, what the rotation size model determines about the detection gap for silent attrition compounding into an unsustainable schedule, and what the signal-to-noise ratio definition determines about the tuning backlog's prioritization accuracy. None of these properties are typically labeled as decisions at the time the on-call policy is written. The alert volume budget is not set because the policy focuses on who is on-call and when. The rotation size is not monitored because it was set deliberately at formation and the degradation is invisible without a continuous measure. The signal-to-noise ratio is not tracked because the incident system was designed to count firings, not to classify interventions.

Property 1: The alert volume threshold and the burnout accumulation surface. The burnout accumulation surface is the gap between the documented on-call load and the actual cognitive load experienced by the on-call engineer. The gap grows as non-actionable alerts accumulate: each post-incident review that adds a new low-threshold alert rule adds to the firing rate without adding to the genuine intervention rate; the documented load (incident count) increases while the genuine load (actionable intervention count) stays flat or grows slowly; the difference is the noise that the on-call engineer carries — the late-night pages that turn out to be false alarms, the acknowledgments without action, the context-switching overhead of evaluating a page that requires no response. The threshold decision is the budget that bounds this surface: if the on-call load policy specifies a maximum of 3 actionable alerts per shift and a maximum total alert rate of 6 per shift (implying a minimum 50% actionability ratio), then any new alert rule that would cause either threshold to be exceeded must either replace an existing rule or trigger a tuning sprint before it is added. Without the threshold, the surface has no bound: every post-incident review can add alerts in good faith, and the cumulative effect is invisible in any single review. The threshold converts alert addition from an individual review action into a budget-constrained allocation decision. Connect this property to the observability strategy decision record: the alert rule inventory is a component of the observability strategy — it specifies which conditions in the system are observable and at what sensitivity; the alert volume budget is a load constraint on the inventory; the observability strategy specifies coverage (which failure modes are detected), and the load budget constrains the cost at which that coverage can be maintained; an observability strategy without an explicit load budget treats coverage as unconstrained and implicitly accepts indefinite load growth as new failure modes are discovered and covered.

Property 2: The rotation size model and the staffing change detection gap. The staffing change detection gap is the time between a roster shrinkage event (an engineer leaving the company, transferring, or going on extended leave) and the rotation plan being reviewed against the minimum viable size. The gap exists in every organization that maintains the on-call schedule manually and reviews it reactively: the schedule is updated when it needs updating (an engineer is removed from the schedule because they are leaving), but the cumulative effect on rotation frequency is not calculated and compared against the minimum viable size unless someone specifically runs the calculation. The detection gap is structurally a monitoring problem: the rotation has a defined minimum viable size but no alert that fires when the effective size drops below it. The fix is to automate the monitoring and close the detection gap: calculate the current effective roster size daily from the on-call scheduling tool's API, compare against the documented minimum, and send an alert when the effective size is at or below the minimum plus one engineer (leaving one engineer as buffer before the minimum is breached). The alert is the detection mechanism that converts an invisible compounding process into a discrete, actionable notification. The minimum viable size itself requires explicit specification: for a weekly rotation, define the minimum viable frequency (once-every-6-weeks as a typical sustainable threshold), calculate the minimum roster size that achieves it (6 engineers), add a buffer for expected annual attrition (1–2 engineers), and document the result as the monitored minimum. Connect this property to the team topology decision record: the on-call rotation roster is a team topology artifact — it specifies which engineers can be called for which systems at what frequency; team topology decisions that change which engineers are in which team (reorganizations, transfers, team splits) propagate into the on-call rotation roster and can change the effective rotation size without any explicit rotation management action; the on-call load management decision specifies a monitoring process that is independent of how the roster changes, so that topology changes are automatically reflected in rotation health metrics regardless of the mechanism by which the roster changes.

Property 3: The signal-to-noise ratio definition and the alert tuning backlog prioritization gap. The alert tuning backlog prioritization gap is the absence of a signal that identifies which alert rules account for the most non-actionable pages and therefore have the highest ROI for tuning investment. Without the actionability classification, the alert backlog is sorted by staleness (oldest items at the top) or by engineer preference, neither of which reflects the load reduction that would result from tuning each item. The gap is maintained by a feedback loop: the on-call engineers who experience the noise have the information needed to classify alerts as actionable or non-actionable, but they do not have a structured mechanism to record that classification at resolution time; the managers who own backlog prioritization have access to the unstructured incident records but not to the classification that makes the records useful for load analysis; the result is that the most valuable input for prioritizing the tuning backlog requires a manual review that no one has time to run until the noise has accumulated to the point of causing visible attrition. The fix is structural: add an actionability classification field to the incident resolution workflow as a required one-click selection (actionable / non-actionable / escalated) before an incident can be marked resolved; configure a weekly report that shows the top 10 alert rules by non-actionable count, sorted by the product of firing frequency and average time-to-close; treat this report as the tuning backlog input, with items at the top of the list as the highest-priority tuning work regardless of their age. The actionability classification field produces the required input passively, during the normal on-call workflow, without requiring any additional time from the on-call engineer beyond a single click at resolution. Connect this property to the technical debt decision record: alert tuning is a category of operational technical debt — accumulated noise from well-intentioned rules whose thresholds have drifted from meaningful to noisy; the signal-to-noise ratio definition converts this category of debt from invisible (no metric, no priority) to visible (weekly top-10 report, actionable ROI calculation); the technical debt decision record specifies the governance process for prioritizing technical debt against feature work; the on-call load management decision record specifies the metric that makes alert tuning debt visible enough to enter the prioritization conversation.

The on-call load management ADR: five sections

Section 1: Alert volume budget specification and actionability classification. Begin the on-call load management decision record by specifying the alert volume budget: the maximum number of actionable alerts per on-call shift that is acceptable before the rotation is considered overloaded, and the minimum acceptable actionability ratio (actionable alerts / total alerts fired). Define these thresholds before the on-call policy is operational, not retrospectively after attrition has occurred. A starting specification: maximum 3 actionable alerts per 8-hour shift, maximum 8 total alerts per shift (implying a minimum 37% actionability ratio at threshold), minimum 50% actionability ratio over any rolling 30-day window. Specify the actionability classification itself: an alert is actionable if the responding engineer ran any command, modified any configuration, wrote any post-incident analysis, or made any explicit decision based on the alert's content; an alert is non-actionable if the engineer acknowledged the alert, waited for the condition to clear or confirm, and closed the alert without any of these actions. Add the classification as a required one-click field in the incident resolution workflow. Specify the budget enforcement process: when a new alert rule is proposed (typically in a post-incident review), evaluate its expected firing rate against the current 30-day non-actionable rate; if adding the rule would push the actionability ratio below the minimum or the total alert rate above the budget ceiling, the rule cannot be added without a corresponding tuning action that removes or raises the threshold on an existing rule; document this as a pre-addition checklist item in the post-incident review template. Connect to the observability strategy decision record: the alert volume budget is the load constraint on the observability strategy's alert inventory; the observability strategy owns the coverage specification (which failure modes are alerted), and the on-call load management decision owns the load budget (at what aggregate cost can coverage be maintained); both decisions must be made together and updated together when coverage requirements change.

Section 2: Rotation size policy and minimum viable coverage specification. Specify the target on-call frequency for each engineer in the rotation, the minimum viable roster size that achieves the target frequency, and the attrition buffer to be maintained above the minimum. For a weekly rotation with no additional compensation: target frequency once-every-8-weeks, minimum viable size 6 engineers (once-every-6-weeks is the assumed sustainable floor with buffer), attrition buffer 2 engineers (targeting a steady-state roster of 8 to absorb expected annual attrition of 2 engineers without dropping below 6). Specify the roster monitoring requirement: configure an automated daily check of the effective roster size (engineers currently active, on-call eligible, and not on extended leave) against the documented minimum; alert the engineering manager when the effective size is at or below the minimum plus one buffer engineer; require a formal roster review within 5 business days of the alert. Specify the frequency deviation review trigger: if any engineer's on-call frequency in a given quarter exceeds the target by more than 50% (more than 1.5x the target frequency), trigger a roster review even if the effective size has not dropped below the minimum; the frequency deviation is the signal that the distribution has become uneven and that some engineers are carrying disproportionate load regardless of the aggregate roster size. Specify the on-boarding requirement for rotation addition: new engineers can be added to the rotation after completing a defined number of on-call shadowing shifts (typically 2–3 shifts as secondary responder with an experienced primary) and after demonstrating familiarity with the top 10 most common incident types in the runbook; do not add engineers to the rotation before they are prepared, even to address a roster shortfall, because an unprepared primary responder adds load to the rotation rather than reducing it. Connect to the on-call rotation compensation decision record: when actual on-call frequency deviates from the target by more than 25% (engineers are on-call more often than the documented target), a compensation review must be triggered alongside the roster review; the load model and the compensation model are interdependent, and a load increase without a compensation review is a de facto compensation reduction that the on-call load management decision must explicitly link to the compensation decision record.

Section 3: Signal-to-noise ratio governance and tuning backlog management. Specify the signal-to-noise governance process: the weekly report format, the prioritization criteria, the tuning sprint cadence, and the threshold for declaring an alert rule as a tuning priority. The weekly report should show the top 10 alert rules by non-actionable page count in the prior 7 days, with the following columns per rule: rule name, total pages in the window, non-actionable pages, actionability ratio, average time-to-close for non-actionable pages, estimated weekly engineer-minutes wasted (non-actionable count × average time-to-close). Sort by estimated weekly engineer-minutes wasted, descending — this ranks the tuning backlog by load reduction ROI. A tuning sprint should be scheduled whenever any of the following conditions is met: the total actionability ratio across all rules drops below 50% in a rolling 30-day window; any single alert rule accounts for more than 20 non-actionable pages in a rolling 7-day window; the estimated weekly engineer-minutes wasted by non-actionable alerts exceeds 60 minutes per on-call engineer. The tuning sprint duration should be calibrated to the estimated time required to address the top 3–5 items on the weekly report; in most cases, 2–3 days of focused engineering time is sufficient to reduce the top 10 non-actionable alert rules by 50% or more. Specify that tuning sprint work is categorized as operational technical debt, not infrastructure investment: it does not require a business case, it is pre-approved up to a maximum of 4 engineering-days per quarter, and it takes priority over feature work when any of the trigger conditions is met. Connect to the technical debt decision record: alert tuning is operational technical debt that accumulates every time a new alert is added and every time system behavior drifts from the conditions that calibrated the original threshold; the signal-to-noise governance process is the maintenance cadence that prevents the accumulation from growing indefinitely; without the cadence, the debt grows until it manifests as rotation exit, at which point remediation costs are measured in recruiting and onboarding investment, not engineering-days.

Section 4: Burnout detection model and rotation relief threshold. Specify the rotation health metrics that trigger a formal burnout risk review and the relief actions that can be taken when the risk threshold is crossed. Define three burnout risk tiers. Green: actionability ratio above 50%, effective roster at target size, average actionable alerts per shift below the maximum, no engineer carrying more than 1.5x target frequency. Yellow (early warning): actionability ratio 40–50%, effective roster at minimum plus one buffer engineer, average actionable alerts per shift 75–100% of maximum, or any engineer carrying 1.5–2x target frequency for more than 4 consecutive weeks. Red (intervention required): actionability ratio below 40%, effective roster at minimum or below, average actionable alerts per shift above maximum, or any engineer carrying more than 2x target frequency. Yellow tier response: schedule a rotation health review within 10 business days, identify the root cause of each yellow signal, and produce a remediation plan with a completion target within 30 days; do not wait for the Yellow signals to resolve on their own. Red tier response: immediate rotation health review within 2 business days, temporary load reduction actions within 5 business days (temporarily add engineers from adjacent teams as secondary responders to reduce primary responder frequency; declare a tuning sprint to address the top non-actionable alert sources), and a 60-day remediation plan. Specify the relief actions available at each tier: at Yellow, alert threshold tuning (reduce non-actionable volume), temporary secondary-responder addition (reduce primary frequency), or postponement of non-critical on-call eligibility reviews; at Red, all Yellow actions plus a formal staffing escalation if the roster shortfall cannot be resolved within 30 days through internal means. Connect to the hiring process decision record: the Red tier burnout risk threshold is a staffing trigger — if the on-call roster cannot be restored to target size within 60 days through existing team members returning from leave or new engineers completing on-boarding, a hiring action is required specifically to restore rotation health; this trigger should be included in the hiring prioritization model as a high-urgency trigger that competes with feature engineering headcount on equal terms, since the cost of not addressing it is measured in rotation collapse and senior engineer exit.

Section 5: On-call load review cadence and rotation health dashboard specification. Specify the review cadence for on-call load health, the dashboard components that provide ongoing visibility, and the owner of each component. Weekly: the automated non-actionable alert report is distributed to the engineering manager and the current on-call engineer; the on-call engineer adds a one-paragraph commentary on the prior week's rotation experience (what was noise, what was signal, what required the most investigation time) — this qualitative input captures the load dimensions that are not represented in the metrics (cognitive overhead from ambiguous alerts, complexity of interventions that look like simple close-without-action but required significant context retrieval). Monthly: the engineering manager reviews the 30-day rolling metrics against the Green/Yellow/Red thresholds, reviews the non-actionable alert top-10 report against the tuning sprint trigger conditions, and reviews the effective roster size against the documented minimum; any metric in Yellow tier triggers a rotation health review before the next monthly review. Quarterly: a rotation retrospective with all engineers in the rotation; the retrospective covers the prior quarter's load metrics, the quality of the on-call documentation (runbook accuracy, escalation path clarity, alert descriptions), and the on-call engineer experience rating from each participant on a 1–5 scale; the experience rating is the leading indicator for voluntary exit — a consistent rating below 3 from multiple engineers is a 60–90 day leading indicator for attrition. Dashboard components: actionable alert rate per shift (7-day rolling average with threshold line), actionability ratio (30-day rolling average with threshold line at 50%), effective roster size (daily, with threshold line at minimum viable), on-call frequency distribution (bar chart per engineer per quarter, with target frequency line), and off-hours actionable alert rate (subset of actionable alerts that fire between 10 PM and 6 AM local time, the signal that most directly represents quality-of-life impact). Connect to the team health metrics decision record: the on-call experience rating collected at the quarterly rotation retrospective is a component of team health that belongs in the same system as eNPS, DORA metrics, and developer satisfaction measures; the on-call load metrics are not exclusively an operational concern — they are team health inputs that should be visible to the engineering organization's leadership alongside the other metrics that predict retention risk; a leadership team that sees DORA metrics and eNPS but not on-call load metrics is missing a systematic driver of voluntary attrition in the most infrastructure-experienced engineers on the team.

FAQ

Further reading

• Alerting threshold decision record — the per-alert calibration model that sets the detection threshold for individual alert rules; the on-call load management decision sets the aggregate budget that bounds how many rules can exist at any given threshold sensitivity; the alerting threshold decision specifies each rule's threshold, and the load management decision specifies the governance process that prevents well-intentioned individual rule additions from accumulating into an unsustainable aggregate load.
• On-call rotation compensation decision record — the compensation model for on-call participation; compensation and load are interdependent — a rotation that doubles in frequency without adjusting compensation is a de facto compensation reduction; the load management decision record must specify a compensation review trigger that fires when actual frequency deviates from the documented target by more than a defined threshold, linking the load governance to the compensation governance.
• Incident response playbook decision record — the response procedure for each incident type; the actionability classification field in the on-call load management decision propagates into the incident resolution procedure as a structured field requirement; the playbook and the load management decision are interdependent — the load management decision identifies actionability classification as a required metric, and the playbook specifies the workflow step at which the classification is collected.
• Observability strategy decision record — the signal inventory that specifies which conditions in the system are observable and at what sensitivity; the on-call load management alert budget is a constraint on the observability strategy's alert coverage — coverage goals and load sustainability must be balanced together; an observability strategy that maximizes coverage without a load constraint produces an alert inventory that grows indefinitely as new failure modes are discovered, accumulating noise faster than tuning work can remove it.
• Technical debt decision record — the governance model for prioritizing accumulated technical debt against feature work; alert noise is a category of operational technical debt that accumulates silently and manifests as rotation exit; the signal-to-noise ratio governance converts this debt from invisible (no metric, no priority) to visible (weekly top-10 report, engineer-minutes-wasted ROI calculation) and makes it eligible for the same prioritization process that governs other categories of technical debt.
• Open-source extractor — find the on-call load decisions buried in your AI chat history: the session where an alert rule was added after a post-incident review without evaluating the aggregate load impact, the planning conversation where the rotation size was set without specifying a minimum viable size or an attrition buffer, and the retrospective discussion where engineers mentioned the alert noise was getting worse without that observation being formalized into a tuning sprint trigger — each is a recoverable decision record that explains the structural gap the next rotation health crisis will exploit.