Read run history and retry

A workflow you can't inspect is a workflow you can't trust. Run history is the record of every execution: which records triggered it, which path each run took, what every step did, and where any run stopped. It's the first place to look when something didn't happen — or happened twice.

This guide covers reading the per-node trace, finding and fixing a failed step, retrying from the point of failure without re-running what already succeeded, and the safety mechanisms — idempotency keys, loop and rate guards, an on-failure recovery branch, and versioning — that keep automation dependable while it's live.

Who this is for

Anyone who owns a live workflow and needs to confirm it ran correctly, debug a run that didn't, or recover from a failure.

Before you start

• A workflow that has run at least once.
• Permission to view workflow runs in your workspace.
• A specific run or record in mind if you're investigating something that went wrong.

What's live for reliability
All of it: a per-node trace on every run, retry-from-the-failed-step, idempotency keys so a flow can't double-fire on the same event, loop and rate guards so a flow can't run away, an on-failure recovery branch you can route errors into, and versioning so you can edit a workflow while it's live without disturbing runs already in flight.

Read a run and recover from a failure

1. Open run history for the workflow
   Go to the workflow and open its run history. You'll see each execution with the record that triggered it, when it ran, and its outcome — completed, failed, or still running — so you can spot the run you care about.
2. Read the per-node trace
   Open a run to see the trace, node by node. Each step shows what it evaluated or did — which condition passed, which branch was taken, what an action sent or changed, and what an AI step produced. This is how you confirm a run did exactly what you intended.
3. Find the step that failed and why
   If a run failed, the trace marks the step that stopped it and the reason — a missing field, a webhook that returned an error, a permission issue. You're reading the actual cause, not guessing from a silent non-event.
4. Fix the cause
   Address whatever the trace points to: fill the missing data, fix the webhook endpoint, adjust the condition or the action's configuration. Because of versioning, you can edit the live workflow without disturbing runs already in progress.
5. Retry from the failed step
   Retry the run from the step that failed — not from the beginning. Steps that already succeeded aren't re-run, so a retry won't re-send an email or duplicate a task. Idempotency keys back this up, so the same event can't accidentally produce two runs.
6. Route errors with an on-failure branch
   For workflows where a failure needs a human, add an on-failure recovery branch: when a step errors, the run takes that path — for example, posting to Slack or creating a task for an admin — instead of failing silently.
7. Trust the guards for the rest
   Loop and rate guards stop a workflow from running away — a flow can't trigger itself into an endless cycle or hammer an action. Combined with idempotency keys, that means the common automation nightmares (duplicate sends, infinite loops) are handled for you.

What you get

• A clear, per-node record of what every run actually did.
• The exact step and reason behind any failure — no guesswork.
• Recovery from a failure by retrying from the failed step, with no duplicate side effects.
• Confidence that loops, double-fires, and silent failures are guarded against.

Frequently asked questions

What does the run history show me?

Every execution of the workflow, with the record that triggered it, the time, and the outcome — and inside each run, a per-node trace. The trace shows which condition passed, which branch the run took, what each action did, and what any AI step produced. It's the full story of a single run.

If a workflow fails halfway, do I have to start over?

No. You retry from the step that failed, and the steps that already succeeded are not re-run. So if a run sent an email and then failed at a webhook, retrying picks up at the webhook — it won't send the email a second time. Idempotency keys ensure the same triggering event can't spawn a duplicate run either.

How does KudosCRM stop a workflow from running in a loop?

Loop and rate guards. If a workflow's action would re-trigger itself, the guard stops the cycle rather than letting it spin; rate limits keep a flow from firing an action too aggressively. You don't have to configure this defensively — the guards are built in.

What is an on-failure recovery branch?

It's a path a run takes when a step errors, instead of just stopping. You can route failures to a notification — post to Slack, create a task for an admin — so a human knows when something needs attention. It turns a silent failure into an action you'll actually see.

Can I edit a workflow while it's running live?

Yes. Versioning lets you change a live workflow without disturbing runs already in flight — in-progress runs finish on the version they started on, and new triggers use the updated version. So you can fix a problem the trace revealed without pausing the automation.

Learn more

• Workflows (feature) — The visual flow builder and run history on the feature page.