"Sometimes the best thing you can do to create system-level stability is to abandon component-level stability" — the Erlang **"let it crash"** philosophy. Since you can't prevent every error or test the whole state space, and since "the cleanest state your program can ever have is right after startup," and error recovery is hard and unreliable — the goal becomes to *get back to that clean startup as fast as possible*. Four things must be true for it to work: - **Limited granularity.** There must be a crash *boundary* (an Erlang/Elixir actor, an Akka actor, or a whole microservice instance), and the rest of the system must protect itself from a cascade — typically with circuit breakers. - **Fast replacement.** Restart must be quick: actors restart in microseconds; a Go container or NodeJS process in milliseconds. If startup takes minutes (an aging JavaEE app, a fresh VM), **"let it crash" is not the right strategy** — *don't crash monoliths*. - **Supervision.** A hierarchical supervisor tree restarts crashed children (the supervisor is *not* the work-requesting consumer); it must crash itself if restarts happen too densely, rather than masking an unrecoverable problem. PaaS autoscalers lack this discretion. - **Reintegration.** After restart, callers must resume using the instance — via circuit breakers that auto-reintegrate, or a load balancer's health checks readmitting it to the pool. Counterintuitive but sound: create system-level stability *through* component-level instability — restart fast, isolate crashes, reintegrate automatically. [[Self-Healing Agent Harness]] applies the same self-healing-without-humans principle to AI agent quality: grade-fix-deploy instead of crash-restart-reintegrate, but the same closed-loop shape. --- *Source: [[Release It Second Edition]] (Michael T. Nygard, Pragmatic Bookshelf 2018) — Ch 5 — Stability Patterns*