.AIRetries, replays and restarts
How APIANT automatically retries a failed step on a fixed schedule, and how to retry a failed run, restart it from a step, replay a webhook payload, and handle paused runs and held webhook deliveries.
When a step fails with a temporary error, such as a timeout or an HTTP 503, APIANT pauses the run and tries that step again on a fixed schedule, up to 9 attempts in total over about 8 hours. For failures that are not temporary, or after the schedule runs out, you can retry the run yourself, restart it from a chosen step, or replay its trigger data.
Automatic retries
Which errors are retried
| Retried | Not retried |
|---|---|
| HTTP 429, 500, 502, 503 and 504 | Other HTTP errors, including 400, 401, 403, 404, 501 and 505 |
| Request timeouts | A domain name that does not exist |
| Connection refused, reset, timed out or unreachable | A request blocked by platform policy |
| A response cut off mid-read, temporary DNS failures | |
| Error messages matching a platform-wide list of known temporary errors |
The platform-wide list is maintained by APIANT and applies to every account. It matches text in the error message, so an error from the right-hand column is still retried when its message contains an entry on that list. If you think an error should be treated as temporary, ask Claude to check the current list and prepare the evidence to send to APIANT support.
A 401 is handled differently: unless the API is on the platform's 401 exemption list, it turns the automation off. See Error alerts.
The schedule
| Attempt | Waits before the attempt |
|---|---|
| 1 | Runs immediately |
| 2 | 1 minute |
| 3 | 2 minutes |
| 4 | 5 minutes |
| 5 | 10 minutes |
| 6 | 30 minutes |
| 7 | 1 hour |
| 8 | 2 hours |
| 9 | 4 hours |
The schedule is the same for every automation and cannot be changed.
While it waits, the run shows as Snoozed in Execution History. Each retry runs the failed step again; steps that already succeeded are not run again. If the ninth attempt fails, the run continues to the step's error subroutine if it has one; otherwise the run ends in error and your error alerts fire.
When automatic retry does not apply
- Steps set to continue on error. When the step continues past the error, the error is passed to the next steps as data and the step is not retried.
- Records from a polling trigger. A record whose step fails with a temporary error is not paused. It ends in error and, because it was not marked as processed, the trigger fetches it again on its next poll.
- Web service automations. The caller is waiting, so the run is not retried. See Web service automations.
- Inside a parallel step. The retry re-runs the whole parallel step, not only the failed branch.
- Inside a called automation. A failure inside an automation called with Execute Automation re-runs that automation from its first step.
Ask Claude "which retries are pending?" to see paused retries, soonest first, with the attempt number and error of each.
Retry a failed run from Execution History
Selecting Retry… on a failed run opens a dialog that asks which data to use for the retry.
-
Open the failed run in Execution history and select Retry…. To retry every failed run of the automation, select Retry all errors… on the run list.
-
Choose a retry mode:
Mode Available for Effect Re-use stored data Any failed run with stored data Uses the data recorded in the original run Manually edit stored data A run with a single record Opens the recorded data as JSON for you to edit first Attempt to fetch data again Polling triggers Discards the stored data and fetches the records from the app again. If the data can no longer be fetched, the run can never be retried. -
Choose where to start: Retry from failed (labeled Resume from failed action when you edit the data) skips the steps that already succeeded and starts at the failed step. Start at first action runs every step again.
Each retry creates a new run. With Re-use stored data, polling runs that processed several records are skipped, so records that already succeeded are not processed twice.
A retry cannot run when the automation has data storage turned off, because no data was kept.
Ask Claude to recover a run
Claude has finer control over an existing run. Describe what you want:
| Ask for | What happens |
|---|---|
| "Retry the failed runs of the invoice sync from this morning" | Each run starts again as a new run from its recorded trigger data. Up to 10 runs per request; polling runs with several records are refused. The in-app assistant can do this too. |
| "Change the email in step 2's output to jordan@example.com and restart the run from step 3" | Claude edits the recorded output, then restarts the same run from the step you name. Earlier steps replay their recorded output without calling the app again. On a polling run, Claude restarts one record at a time. |
| "Run the order webhook again with this payload" or "replay the trigger from run 1482" | A new run starts with the JSON you supply, or with the trigger data of the earlier run. The replay skips duplicate detection and signature checks and does not go through the webhook URL. |
Restarting and replaying are available from Claude Code, not the in-app assistant.
Restarting re-executes the step you name and every step after it. Any step that creates or changes records in an app does so again.
Paused runs
Runs wait on timers, forms, approvals, chat goals, fan-out latches and retries. Ask Claude "what runs are waiting?" to list them across your automations, longest-waiting first.
A run paused on a timer, form or approval stays paused while its automation is turned off. Once the automation is back on, a due timer resumes the run, and a pending form or approval can be completed again; while it is off, submissions and decisions are refused. Turning an automation off cancels its pending automatic retries instead: those runs end and do not resume. To end a paused run so it never resumes, ask Claude to cancel it, or use Cancel all snoozed… in Execution History. Cancelled runs end as halted.
Webhook deliveries that did not run
APIANT stores each delivery to a webhook trigger when it arrives. Web service calls are not stored. A stored delivery waits instead of running when:
| Cause | When it runs |
|---|---|
| The automation is turned off | When the automation is turned back on |
| The account has reached its monthly instant trigger or task limit | After the monthly usage reset |
| The automation uses an app that APIANT has temporarily disabled | When the app is enabled again |
Ask Claude "which automations have unprocessed webhooks?" to see the counts per automation. A delivery to an automation that was deleted is discarded.