On-Call Culture & Runbooks

Closest to 'only careful code review or runtime testing' (d7). The detection_hints note that tools like PagerDuty and OpsGenie exist but automated detection is explicitly 'no'. The signs — missing runbooks, recurring incidents, burnout — only surface through careful operational observation over time (e.g. reviewing alert volumes, postmortem outcomes, attrition). No linter or static tool catches cultural debt; it manifests in production through repeated incidents and engineer exhaustion.

Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix suggests tracking and reducing toil, but the common_mistakes reveal systemic problems: no runbooks to write, rotation imbalances to fix, compensation structures to change, and postmortem culture to reform. These changes span engineering teams, management, HR, and operational tooling — well beyond a single-component fix. This is a cultural and organizational refactor, not a code change.

Closest to 'strong gravitational pull' (b7). On-call culture applies across all engineers in web and cli contexts per applies_to. A poor on-call culture shapes every future hire, every system design decision (reliability targets, alert thresholds), every incident response, and every postmortem. It imposes a persistent, cross-team productivity and morale tax. It doesn't quite define the entire system's shape (b9) but it strongly influences how every operational change is made.

Closest to 'serious trap' (t7). The canonical misconception is explicit: 'More alerts means better monitoring.' This directly contradicts reasonable intuition — developers naturally assume more monitoring signals more safety. In practice, alert fatigue means more alerts can reduce effective monitoring. This is a well-documented SRE gotcha that contradicts intuitions imported from adjacent practices (logging, metrics), scoring it at t7 rather than t9 because it is documented and increasingly well-known in the SRE community.