Retry
For transient failures
Use retry with backoff when the workflow design is sound but the failure looks temporary.
For wrong context shape
Move the work to current, isolated, or named session form when the problem is where context lives.
OpenClaw automations
Automation debugging and recovery
Use this page when you need to diagnose weak OpenClaw automations by symptom, identify the likely workflow-design cause, and choose the smallest effective recovery action.
Debug the workflow
Most automation failures are design failures before they are model failures.
Start from the symptom you can observe
The visible failure pattern usually points to the broken layer
Ask what actually happened:
- did the job fire at the wrong kind of time?
- did it lose needed context?
- did it say it was working without producing a real deliverable?
- did it stop moving and keep reporting the same state?
Common symptom-to-cause map
Use the symptom to find the likely workflow problem
- Wrong kind of wakeup: wrong timing model, usually cron vs heartbeat
- Lost context or too much noise: wrong session or routing model
- No clear result: no explicit artifact target
- “Working on it” but never finished: shallow interim output mistaken for completion
- Repeated same stuck state: no stall recovery behavior
Recovery options are not all the same
Pick the smallest fix that matches the failure
Reroute
Restart
For blocked stages
Restart or reroute the blocked stage when no real artifact changed and the workflow is effectively stalled.
Repair
Prefer narrow repair over broad rebuild
If one stage is broken, recover that stage first and preserve upstream work that is already good.
Observable receipts matter
You can only debug what the workflow makes visible
Debugging is much easier when workflows leave receipts: final files, validated paths, status changes, handoff artifacts, run history, or explicit queue states. If the automation does not expose enough evidence, improving observability may be part of the repair.