When a workflow breaks: the recovery plan
Workflows fail. The difference is what happens next. How to build failure handling and a recovery plan before you need it.
Nikolas Gannon · · 1 min read · Automation
A workflow that never fails does not exist. The difference between a good system and a gamble is what happens when it does.
The three parts of recovery
- Alerting. The failure notifies a person. Silent failures are the dangerous ones.
- Fallback. A defined outcome: retry, stop cleanly or route around. The workflow never hangs in a half state.
- Owner. Someone is responsible when it breaks, and they are reachable.
For a deeper look, see Automation ROI: how to calculate it.
Why most builds lack this
The happy path is tested; the failure path is not. A workflow looks finished until the missing field arrives, and then it fails silently, and the business finds out from a customer.
What a good build includes
- Edge-case testing before launch
- Alerts wired to a person
- A clear fallback for each failure type
- A first-week review after real traffic
What it feels like
The workflow runs. You do not think about it. If something fails, you hear before the customer does. That is the reliability standard.
The honest note
Recovery is not glamorous. It is the difference between a tool and a liability, and it is why the edge-case QA step exists in every build.
If you want workflows with a recovery plan, that is the standard to ask for.
Free resource: Workflow automation audit workbook
Free resource: Software bill review checklist
Read next: Reliability: the automation feature nobody sells · The proposal timeline: from scope to handoff · When not to automate: the honest guide
Questions
Do workflows break?
Yes. The question is whether the failure is loud, visible and recoverable.
What is the most common failure?
An edge case that was never tested: a missing field, a duplicate or a failed connection.
What makes recovery fast?
Alerting, a defined fallback and someone responsible for fixing it.