Diagnosing a Failed Run Without Reading Raw Logs
A failed workflow run can now be diagnosed automatically, so you get a plain answer to what went wrong instead of a raw execution log to parse yourself.
When a workflow run fails, you no longer have to start by reading through the raw log line by line — there's now a dedicated diagnosis you can pull for that specific run.
What it does
Every failed execution has its own diagnosis endpoint. Instead of opening the run's history and manually working backward from a stack trace or an error string to figure out which step actually broke and why, you get a direct read on the failure for that run.
How this differs from the run history view
Workflows already shows a run-by-run history with the raw logs for each execution — that view isn't going anywhere, and it's still where you'd go to see exactly what happened step by step. The diagnosis endpoint is a separate, more targeted layer on top of it: instead of reading the logs yourself, you get help identifying what specifically went wrong on the run that failed.
Why this matters
Every serious automation tool eventually has to answer "why did this fail" for its users, and the usual answer is a log viewer and your own judgment. Applying an automated first pass to the failure itself — the same idea behind our AI-drafted workflows, just pointed at debugging instead of authoring — means you spend less time cross-referencing timestamps and more time fixing the actual problem.
If a run has ever failed at 3am and left you scrolling through logs before your first coffee, this is built for exactly that moment.