What Should Happen When an Automation Step Fails?

What this question usually means

The rewrite cluster is: which errors are retryable, how long to wait, how to avoid sending twice, and who owns recovery. People also ask the product to “just keep trying.” Unbounded retry on a terminal error creates duplicates and hides the owner.

A timeout, a 429, or a flaky network may be retryable. A missing field, a rejected authorization, or a business rule that says no is usually terminal. Write that distinction before you add retries.

Materials or prerequisites

Bring failure, retry, and recovery rules, a sample of a failed payload, and the account boundary. If you have a recorded run, bring that. If you only have a design, say so — you can plan retries, but you cannot claim they worked.

Step 1: Label each failure as retryable or terminal

Retryable means the same request might succeed later without changing the business decision. Terminal means a person or a different input is required. Write examples from your process, not a generic HTTP list.

Step 2: Set backoff and a retry budget

Name the wait, the maximum attempts, and what happens when the budget is exhausted. Infinite retry is not a recovery path. Exhaustion must page a named owner.

Step 3: Prevent duplicate actions

If a step sends a message, creates a record, or charges a fee, retries must be idempotent or gated. Record the idempotency key or the check you will use. A second “success” that doubles the action is a new failure.

Step 4: Name the recovery owner and the handoff

When retries end, who sees the run, what evidence they get, and what they are allowed to do. If the next action needs a service you have not authorized, the handoff must say that rather than implying the owner can click through.

Step 5: Test the failure path with representative data

Use a sample that should fail, a sample that should retry then pass, and a duplicate event. Every workflow needs testing with representative data before wider use. If you later inspect a real stop, use the recorded run — do not invent a success.

Verification

A second person can tell retryable from terminal, see the retry budget, see how duplicates are prevented, and name the recovery owner. If you claim a run recovered, point at the recorded run. Design notes are not that evidence.

Limits that stay in error handling

Connected services and credentials require separate authorization. Every workflow needs testing with representative data before wider use. Flowspoken may describe retry plans and observed results from recorded workflow runs.

Do not claim a workflow ran or succeeded without run evidence. Do not imply access to a service before its connector is authorized. A retry policy is not proof the downstream system accepted the call.

What Flowspoken does in this workflow

Flowspoken surfaces failure branches and can explain why a workflow run stopped when you share the run. It does not mark a run successful because the happy path looked clean in the diagram.