Investigate failed executions with the AI assistant
Hand it a failed run: it pinpoints the failing step, explains the cause, fixes the workflow in place and runs it again.
When a run fails, the time sink is usually not fixing it but finding it — which of several hundred events actually went wrong, and in which field. This page shows how to hand that job to the AI assistant.
Start from the execution detail page
- Open the detail page of the failed run.
- Open the AI assistant: two shortcut buttons, diagnose and retry, appear above the input box. Click diagnose — or simply ask why this run failed; both work.
- Its answer names the failing step, gives the direct cause of the error, and says how the corresponding workflow configuration should change.
- Once you agree with the fix, let it edit the workflow directly and run it again.
What it actually sees
The platform does not shove the whole run log at the model — that would be expensive and would bury the signal. What the assistant gets is a compressed body of execution evidence:
- the run's overall status, progress, start and end times and the top-level error message;
- a status timeline for every step: its status, type, retry count, duration and whether auto-resume ever rescued it;
- full detail only for the failing step and the current one: inputs, outputs, stack trace and that step's configuration;
- and the workflow's own structure, so it can tell a configuration mistake from an external system problem.
The evidence is assembled server-side under your permissions: a run you cannot see, the assistant cannot read either. The same applies to team-shared workflows, judged by your standing in that team.
"Hand it to the AI to fix" inside the editor
When problems show up before you even run it, there is a shorter path:
- the diagnostics panel at the bottom of the editor can hand a single issue — or all of them at once — to the AI to fix;
- the entry point on the step properties panel opens the assistant with that step's full context, so you never copy YAML by hand;
- the assistant still produces a diff afterwards; nothing is saved until you confirm, and the change joins the editor's own undo history.
Common failure types and how far it can take you
| Failure type | What the assistant can do |
|---|---|
| Configuration mistakes (a variable that resolves to nothing, a wrong field type, a step left unconnected) | Pinpoints the exact field and gives the fix; you can have it apply the change on the spot. |
| A missing or expired credential | Names which service's authorization is missing; you then add or replace it on the Integrations page. |
| Errors from an external API (rate limiting, insufficient permission, rejected parameters) | Explains what the upstream response means and suggests a retry policy or parameter change — but problems with the upstream account itself you must handle in that provider's console. |
| A code step throwing an exception | Reads the script and the stack trace to pin down the behaviour, then hands back a corrected script. |
| A run interrupted midway | Uses the resume record to say which steps already succeeded and where it is safest to pick up again. |
In bulk: what failed recently
Open the assistant on the execution list page and one of the shortcut buttons is "show recent failed runs" — handy for a morning sweep of last night's scheduled jobs before drilling into each one.
Read next
- Breakpoint Debugging — When you need to pause midway and inspect variables, use breakpoints rather than after-the-fact diagnosis.
- Auto-Resume — Interruptions themselves can be configured to resume automatically.
- Execution Monitoring — How to read the event stream, the logs and the cost.