An automation failed: what to check before retrying

An automation reports an error and someone suggests clicking “Retry”. First, answer a more specific question: what still needs doing? The missing part might be the action, its confirmation or a later step. Restarting the whole workflow can help in one of those situations and make the others worse.

For a founder or a small team, an investigation needs to continue even when the person who built the integration is unavailable. This guide provides a timeline and a worksheet for separating confirmed facts from unknowns. The example is fictional: it does not describe a Frihet incident or use real services, customers or credentials.

The screen error and the state of the work

A timeout means a wait ended without a response arriving in time. It does not tell you whether the destination stored anything. AWS explains this problem through a request that might have created a resource even though the caller received no confirmation. Resolving that uncertainty means identifying both the effect and its origin.

Use three states: effect confirmed, absence of effect confirmed and unknown. “I cannot see it on my screen” belongs in the third while filters, another account, a delayed index or a running attempt could explain the result. Record who checked the state and when: an observation has context, not an unlimited lifetime.

A timeline that changes the decision

Imagine a workflow that creates an internal task and then records its reference in a tracking sheet. Everything below is hypothetical. The times use one simulated clock; in a real investigation, preserve the time zone and source of each timestamp.

The next step is to recover tracking through its documented procedure. Restarting from “create task” would revisit completed work. If the last row merely said “I cannot see it in the sheet”, we would still need to rule out a delay, a filter or an active process before writing there.

The operation reference stays stable; the attempt identifier changes with each execution. A received event and a created task also have different identities. Preserve their relationships so that two attempts at one job are not confused with two legitimate jobs.

Keep a worksheet someone else can continue

Start by preserving existing records and containing new writes through the pause mechanism designed for that workflow. Pausing does not undo completed work or guarantee that in-flight requests will stop. Check the queue and pending retries before assuming nobody else will act.

Copy this worksheet into an internal record with appropriate access. Link to evidence rather than pasting secrets or personal information into shared documents. Add each correction with a date, leaving the earlier observation intact.

Incident: [internal reference]
Intended operation: [one specific outcome]
Provider / account / environment: [destination context]
Operation / event / attempts: [IDs and relationships]
Workflow version: [version that ran]
Last confirmed step: [evidence and timestamp with time zone]
Effect state: [confirmed / absence confirmed / unknown]
Destination evidence: [reference, query and visibility limits]
Work still active: [requests, queue and pending retries]
Retry contract: [documentation, scope and time window]
Missing information: [evidence needed for a decision]
Next action: [read or narrowly scoped recovery]
Owner / next review: [person and date]
Later outcome: [new evidence without overwriting the earlier record]

“Absence confirmed” needs stronger evidence than an empty search: for example, a destination-documented rejection before execution, with other attempts ruled out. If you cannot justify that state, keep it “unknown”.

An idempotency key has limits

Check the provider’s contract for the specific request, account and environment. A key that protects one write does not automatically protect a later notification or another service. Nor can it be attached retrospectively to a request already sent without it. The worksheet should link to the applicable documentation, rather than merely saying “we have idempotency”.

Stripe’s idempotent requests — API v1 reuse the stored result of the first execution, including 500 errors. Stripe checks parameters and can remove keys once they are at least 24 hours old; reusing a removed key starts another request. Its error guide warns of possible effects after a 500: changing the key or waiting for it to expire does not establish that an uncertain action can safely be repeated.

That window belongs to Stripe. For another destination, record its own window, the identity it treats as a repeat and how it handles concurrent requests. If recovery requires changed parameters, treat that as a new decision and review the previous effects first.

Decide from the evidence, step by step

The following table proposes an operational approach, not a universal provider policy. It separates investigation from authorization to change data.

Irreversible or high-impact writes require human review of the proposed recovery. Neither a key nor a green indicator provides an “exactly once” guarantee for the entire journey.

Check who else will retry

The automation tool, API client and provider may each have their own retries. With Stripe webhooks, a manual resend does not cancel automatic retries; events may also repeat or arrive out of order. Resending an event is not the same as idempotently retrying an API write: these are separate mechanisms.

Before closing the worksheet, check the destination’s current state, unfinished steps and attempts that could arrive later. Assign someone to observe the next execution. Completing the worksheet does not resolve the work: if an outcome remains unknown, keep the incident open with an owner and a review date.

Afterwards, reconsider whether the workflow should remain automated using the eliminate, automate and delegate approach. If it connects to Frihet, start with the developer documentation and integration catalogue to locate the relevant interface. Keep this worksheet beside the workflow: the next person should be able to find its last confirmed state without rebuilding the story from a chat.

Technical sources checked on 14 September 2026. The worksheets, decisions and DEMO references are original teaching examples, not instructions to execute changes in a live service.