Get a failing automation under control
Contain the immediate risk, inspect the run evidence, repair the agreed path and test the workflow before normal operation resumes.
Choose the closest failure
Only routes that have passed the current publication gates appear here.
Specific migration directions remain in reviewed planning until their route, evidence and delivery scope are approved. Start with the current estate and the reason to move.
Get a failing automation under control before you retry it.
A green run is not a repair standard if the provider state or downstream record is still uncertain.
Decision boundary: Do not repeat a consequential action until the earlier outcome is known; a blind retry can duplicate messages, records, payments or tasks.
- 01Bring the workflow and time window
Share the relevant workflow or scenario, recent run IDs and when the problem began.
- 02Describe expected and actual behaviour
State what should have happened, what did happen, and which people or systems are affected.
- 03Capture provider and record state
Check the target system before replaying work, especially when an execution timed out or partly succeeded.
- 04Set the non-repeat condition
A repair should include a test, owner and prevention note—not simply make one run appear successful.
- Contain the fault
The workflow is failing, duplicating actions, losing data or behaving differently after a provider change.
- Inspect the run evidence
Contain → capture evidence → reproduce → repair → reconcile → prevent
- Repair the failing path
Do not rerun consequential steps until the previous provider outcome is known.
- Approve any replay
A blind retry creates a duplicate message, record, payment or task.
- Reconcile affected records
A contained incident, an evidence-backed diagnosis and a repair route with prevention notes.
Describe what happens now. The service label can come later.
The source page and intent remain attached to the request so the first review starts with useful context.
Get help with your automation