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.
- Capture the event
The workflow is failing, duplicating actions, losing data or behaving differently after a provider change.
- Resolve context
Contain → capture evidence → reproduce → repair → reconcile → prevent
- Apply the rule
Do not rerun consequential steps until the previous provider outcome is known.
- Human control
A named person reviews ambiguity or consequential action for help with a broken or unreliable automation.
- Verify the effect
Read back the important state, record exceptions and confirm the next owner.
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