Swiss Cheese Model: Layered Defenses Against Failure

Why it exists

To move beyond blaming a single cause for a major failure. Complex systems rarely fail due to one error; they fail when multiple, independent safeguards fail simultaneously or in sequence. This model provides a mental framework for analyzing these compound failures and building more resilient systems.

The mental model

Picture your system's protections as a stack of Swiss cheese slices. Each slice is a different defense: a firewall, a monitoring alert, a code review process, or an operational runbook. The holes are latent weaknesses or active failures in those defenses, like a misconfigured firewall rule, a muted alert, or a gap in test coverage.

How it works

A threat or hazard is like a rod trying to pass through the stack. Most of the time, it hits a solid part of a cheese slice (a working defense) and is stopped. A major incident only happens when the holes in all the slices align, creating a clear path for the threat to pass through unimpeded. This "trajectory of accident opportunity" shows how multiple small, unrelated failures can conspire to cause a catastrophe.

When to use it

This model is essential for conducting blameless post-mortems. It shifts the focus from "who made the final error?" to "which defenses failed, and why?". It's also a powerful tool during system design to proactively build layered defenses, ensuring no single failure can take down the entire system. Use it to analyze incidents involving human operators, software bugs, and infrastructure failures.

When not to use it

The model is a conceptual framework, not a quantitative risk calculation tool. It's less useful for simple, single-cause failures. It can also be misapplied to oversimplify complex interactions, as the "holes" (failures) are not always independent and can sometimes influence each other (e.g., one failure increases the likelihood of another).

One canonical example

A developer pushes a buggy config file (hole 1: human error). The automated pre-deployment check fails to catch the specific syntax error (hole 2: gap in CI/CD). The canary deployment alerting is misconfigured and doesn't fire (hole 3: monitoring failure). Finally, the on-call engineer's runbook for manual rollback is outdated (hole 4: operational process failure). The holes aligned, and a site-wide outage occurred. No single failure was the sole cause.