What Heinrich’s 1:29:300 Rule Reveals About Preventing Online Outages

Heinrich's Law, formulated in the 1930s, observes that for every major accident there are on average 29 minor accidents and 300 near‑misses or hazards, often visualized as a 1:29:300 pyramid. The law implies that serious failures are the cumulative result of many smaller problems.

Core Principles

Accidents are preventable : Managing the 29 minor incidents and 300 hidden hazards reduces the probability of a major failure.

Near‑misses are early warnings : The 300 near‑misses act as an alarm system; ignoring them increases risk.

Safety must be systematic : Accidents stem from gaps in processes, management systems, or culture, requiring continuous, system‑wide improvement.

Typical Applications

Industrial production : Regular safety inspections, employee behavior standards, and incentive‑based hazard reporting eliminate many of the 300 hazards and address the 29 minor incidents.

Aviation : Detailed pre‑flight checks, strict pilot training, and recording of tiny anomalies prevent a loose screw (hazard) from becoming a component failure (minor incident) and ultimately a crash (major accident).

Medical safety : Recording medication errors or small surgical mishaps and analysing them improves processes and prevents severe medical incidents.

Implications for Online Systems

Never underestimate small problems : A null‑pointer exception, a slight latency increase in a non‑core API, or a UI glitch can be signals of the "29" or "300". Treating them as temporary hot‑fixes allows technical debt to accumulate into a major outage.

Near‑misses are valuable data : Issues discovered during a gray‑scale release, a pressure‑test bottleneck, or a configuration error that is rolled back reveal weak points and should be acted upon.

Post‑mortems must dig deeper : Beyond the immediate cause, investigate why the faulty code reached production, why tests missed it, why code review failed, and whether the release process needs improvement.

Build a hazard‑reporting culture : Encourage team members to expose potential risks, unreasonable designs, or process flaws even if they have not yet caused an outage.

Classification of Online "Incidents"

300 hidden hazards ("timed bombs")

Technical debt: outdated libraries, hard‑coded values, undocumented complex code, poor architecture.

Configuration risk: numerous unchecked config items, chaotic management, manual dependencies.

Monitoring blind spots: missing core‑business metrics, unreasonable alert thresholds, incomplete logs.

Insufficient test coverage: low unit‑test coverage, missing integration/end‑to‑end tests, ignored edge cases.

Process defects: informal release procedures, ad‑hoc change management, lack of practiced emergency plans.

Knowledge gaps: only a few know critical modules, outdated or missing documentation.

Bad operational habits: reckless high‑risk commands in prod, weak passwords, credential sharing.

Non‑critical bugs that degrade user experience (e.g., UI misalignment, rare calculation errors).

29 minor incidents ("yellow‑card warnings")

Brief service hiccups (instance restarts causing temporary failures).

Partial feature unavailability or performance degradation (e.g., image upload failures, API latency spikes).

Frequent alerts that self‑recover (e.g., short CPU spikes).

Minor bugs that users notice but can work around (e.g., avatar change failure, occasional search ranking issues).

Resource limit warnings (e.g., connection‑pool exhaustion, disk space nearing threshold).

1 major failure ("red‑alert")

Extended core‑service outage.

Large‑scale user impact on essential functionality.

Data loss or severe corruption.

Significant reputational or financial damage.

Metrics to Surface the Iceberg

Online bug count and trends

New bugs vs. resolved bugs – reflects development quality and fix speed.

Backlog size and severity distribution – high‑severity backlog signals major risk.

Average bug resolution time (MTTR for bugs).

Code quality metrics

Cyclomatic complexity – high values indicate hard‑to‑maintain code.

Code duplication rate.

Static analysis warning count.

System stability and performance

Service availability (SLA/SLO).

Error rates (API errors, business‑operation errors).

Average response time and percentile latencies (P95, P99).

Resource utilization and saturation (CPU, memory, I/O, network, DB connection pool).

Change and release metrics

Change success rate.

Incidents caused by changes.

Release frequency – healthy frequent releases indicate agility when quality is ensured.

Alert and incident metrics

Alert count and severity distribution – too many low‑value alerts cause fatigue.

Mean time to detect (MTTD) and mean time to recover (MTTR) for incidents.

Related Theories

Murphy’s Law – Anything that can go wrong will go wrong.

Domino Theory – Accidents cascade like falling dominoes; breaking any link prevents the chain.

Iceberg Theory – Visible damage is only the tip; hidden losses and systemic causes lie beneath.

Pareto (80/20) Principle – Roughly 80% of accidents stem from 20% of causes.

Bauer’s Law – The more complex a system, the higher the probability of a major accident.

Four‑No‑Pass Principle – Do not stop until root cause, responsible parties, corrective actions, and education are all addressed.

Swiss‑Cheese Model – Multiple defensive layers each have holes; an accident occurs when holes align.

Broken‑Window Effect – Ignoring small problems signals neglect, leading to larger disorder.

Systemic Action Guide

Embrace a "small‑issues‑matter" culture : Treat every "29" and "300" with high vigilance and establish rapid, thorough response mechanisms.

Implement rigorous post‑mortems : Dig deep into root causes, enforce improvement actions, and track outcomes to close the loop.

Strengthen observability : Build comprehensive logging, metrics, and tracing so every corner of the system is transparent.

Invest in the "invisible corners" : Pay down technical debt, refactor complex modules, automate testing, enforce code reviews, and adopt chaos engineering.

Raise team risk awareness and systems thinking : Ensure everyone understands how their work impacts overall safety.

Practice continuous drills : Maintain up‑to‑date emergency plans and run realistic failure rehearsals regularly.

Drive data‑guided continuous improvement : Use collected metric trends to spot bottlenecks and prioritize optimizations (e.g., high bug counts or modules with rising complexity).