Infrastructure learned to heal itself years ago: health checks, restarts, failover, autoscaling. A dead container at 3 a.m. is nobody's emergency anymore.
Business processes never got the same treatment. When a flow breaks (the invoice doesn't post, the order confirmation never sends, the sync writes half a record), the default outcome isn't recovery. It's silence. The failure sits in a log nobody reads until month-end reconciliation or a customer complaint surfaces it, weeks after the fix would have been trivial.
The gap has a cause worth naming: process failures are a different species. Infrastructure fails when a component dies, and a restart is a cure. Processes fail when the world changes: an API returns a new error shape, a vendor renames a field, a document arrives in a layout nobody anticipated, a token quietly expires, etc. Restarting a flow against a changed world just reproduces the failure. Self-healing for processes has to mean something else, and what works in practice is a ladder: each rung handles what it can and passes the rest up, with context attached.
The ladder
1. Retry with judgment. Transient and permanent failures are different animals, and the flow has to know which it's facing. Timeouts and 502s get retries with backoff and a budget. A validation error gets zero retries, because the four-hundredth attempt to post a malformed invoice fails exactly like the first (retrying the unretryable isn't resilience; it's denial with a scheduler).
2. Fallback paths. A second source for the same data, a cached last-known-good value, a degraded mode that does less but keeps the process moving; each acceptable only when the output is marked as degraded. A fallback that pretends to be the primary is a data-quality incident on a delay.
3. Quarantine with context. The failed item gets parked (not dropped, not endlessly retried) together with everything a human needs: the input, the step, the error, what was attempted. And the flow keeps processing everything else; one poisoned record shouldn't stop the other nine hundred.
4. Diagnose with AI, repair deterministically. The newest rung, and the one worth being precise about. A model is well suited to reading a failure (this response changed shape, this document is a new layout of a known type, this is probably the same customer under a different name) and drafting the classification or the corrected mapping. The draft then goes through the normal validated path, or lands with a human as a one-click approval. The model diagnoses; the repair still executes through steps that can be tested and audited. An AI that silently edits production data to make errors disappear isn't self-healing. It's self-concealing.
5. Escalation that names a person. The top of the ladder is not a dashboard. It's a message where the owner already works (mail or chat), saying what broke, what was tried, and what one decision is needed. Every flow has an owner by name; "the team" is nobody at 3 a.m., and equally nobody at 3 p.m. If the escalation carries a proposed fix from rung four, the human's job collapses to reading and clicking approve.
The anti-pattern wearing the same name
Plenty of automation advertises self-healing and implements self-hiding: catch-all handlers, silent skips, unbounded retries that eventually "work" by exhausting the problem, errors swallowed so the run reports green. The tell is a flow that never fails. A process that interacts with the real world and reports years of unbroken success isn't resilient; it's mute.
The metric worth watching isn't failure count; it's time-to-detection and time-to-resolution. Failures are the world changing, which means they're guaranteed. What's optional is finding out in minutes with context, versus in weeks from an angry email.
Why the ladder only gets built once
Nobody re-implements five rungs of failure handling in every script; that's why scattered automation stays at rung zero. Build the retry budgets, quarantine, and escalation into the runtime, and every flow inherits them. It's quietly one of the strongest arguments for running processes through a shared execution layer; this is roughly the posture flow8 takes, with failure handling as part of the floor rather than each author's private afterthought.
The end state worth aiming at is unglamorous: processes still fail, regularly, because the world keeps changing, but each failure arrives pre-diagnosed, context attached, proposed fix waiting, in front of a named person who resolves it before their coffee cools. Not the absence of humans; the efficient use of them.
Curious where others draw the line on rung four: how much repair do you let a model draft before a human sees it?