Recover an interrupted routine

Routine recovery continues interrupted work using saved results. Completed steps are reused, and a top-level foreach can also reuse completed batch items. An owner explicitly starts recovery; opening a conversation does not restart work.

Availability

Recovery is available to all accounts for new supported routine runs. Text/JSON routines save checkpoints automatically; no account or routine activation request is needed. Runs started before the rollout do not acquire checkpoints retroactively. Runs with unsupported inputs or results can still execute, but cannot recover after worker loss. See When recovery is unavailable.

Reconnect, recover, or start again

Action	What happens
Reopen or refresh the conversation	Reconnects to a run that is still executing and reads its progress. It does not start a recovery attempt.
Resume saved work	Starts a new attempt using an eligible interrupted run's saved input, state and completed results.
Run	Starts the routine again from the beginning. It does not reuse an interrupted run's execution checkpoints.
Cancel this run	Ends the interrupted run's recovery eligibility. It does not undo external actions already performed.

Closing a browser tab normally leaves the worker running. Worker loss is different: there is no longer a healthy execution to reconnect to. The platform uses a worker lease, renewed every 30 seconds, to distinguish these cases. After worker loss, the lease expires about three minutes after its last renewal. A run with a live lease cannot be taken over by recovery.

Resume saved work

These steps apply when an interrupted run has compatible saved checkpoints.

1. Open the routine's own conversation and look for Routine interrupted above the composer. It shows how many steps and batch items have saved results.
2. Review the last unfinished work. If it could have sent a message, published content or changed a record, check the connected service before retrying.
3. When prompted, acknowledge that unfinished work may already have performed external actions and that retrying could duplicate them.
4. Choose Resume saved work. The platform checks account ownership, billing eligibility, saved progress and compatibility with the current routine.
5. Follow the new attempt in the same conversation. Saved results are reused; remaining work runs with the normal agents and tools.

Only one recovery attempt can claim the interrupted run. If two tabs request recovery, the second request cannot start another copy. If the response is lost, the app checks the run's status instead of automatically requesting execution again. Stale progress writes are rejected, and workers check execution ownership before starting further steps and tool calls. An external request already in flight may still finish; see Unfinished actions can repeat.

While an interrupted run needs a recovery or cancellation decision, the composer does not start another run. Choose Cancel this run if you want to abandon the saved work. Cancellation remains available without enough balance to resume.

What is saved and reused

Checkpoints contain the original input, execution state and complete saved step results. They are separate from the progress labels and display history in the conversation. Seeing an old result in the chat does not by itself mean the run can recover.

Work at the interruption	Recovery behavior
A completed top-level step with a saved checkpoint	Reuses its result and saved state without running that step again.
A completed item in a top-level foreach	Reuses its saved outcome and keeps the original item order.
An unfinished step or batch item	Retries it after acknowledgement when required.
Partial work inside a sequence, parallel group, loop, condition or router	Retries the enclosing top-level group. Individual completed children inside an unfinished group are not separate recovery checkpoints.

Item recovery applies to a foreach at the top level of the routine. A foreach nested inside another group follows that group's recovery boundary. An item with a saved failure outcome remains a failed result; recovering an interrupted batch does not automatically retry all recorded item failures.

For example, suppose a five-item batch saved items 1 and 2, then lost its worker during item 3 before saving that result. Recovery reuses items 1 and 2, retries item 3, and continues with items 4 and 5. If the batch is nested in an unfinished loop, the loop is retried as a whole instead.

Recovery uses the saved input. Editing the composer does not change that input. Connector authorization is resolved again; an old browser page or open tab is not restored as part of the execution checkpoint.

Unfinished actions can repeat

A completed external action can lack a saved checkpoint

A worker can send a message or update a record, then stop before saving that item's result. Recovery cannot infer from the missing checkpoint whether the external action succeeded. Retrying that item may repeat the action.

Use stable record identifiers and idempotency support where the connected service provides it. Review uncertain actions before acknowledging a retry. Recovery does not guarantee exactly-once delivery or undo earlier changes.

This acknowledgement applies to restarting interrupted work. It does not add approval pauses to a running routine or activate the YAML approval and review fields. See Routines → Approvals.

Billing

Recovery passes the normal account subscription and balance checks. Saved steps are reused without calling their agents or billing hooks again. Their original usage remains recorded; remaining and retried work is billed normally.

An unfinished item that already consumed model or tool usage may incur additional usage when retried. See Usage & billing.

When recovery is unavailable

• The run has no execution checkpoint. Legacy runs and dry-run previews cannot recover.
• The worker still holds a live lease, or the run completed or was cancelled.
• The original execution state was never saved, or the checkpoint expired. Checkpoints are retained for 30 days from the original run; recovery does not extend that period. A run permits at most 32 execution attempts in total.
• The routine definition or relevant execution code changed, the custom routine was disabled or deleted, or its agents are no longer available to the account.
• The conversation is archived or does not belong to your account.

Recovery currently supports text/JSON workflows. Media inputs, local or binary media outputs, model-valued outputs and pause points are outside its supported scope. The run's checkpoint payload is limited to 8 MiB. If the run encounters unsupported or oversized data, it continues execution after disabling recovery and removing its earlier execution checkpoints. Its conversation history remains available. The platform does not truncate data or offer recovery from incomplete saved state. A checkpoint database failure still stops execution, because recovery eligibility and worker ownership must be saved safely.

If the card says the run cannot recover, use Cancel this run before starting a fresh run. Review any external actions that may already have happened. A fresh run starts from the beginning; it is not a way to recover expired results.

See also

• Routines — running, inspecting and stopping routine work
• How a run works — live progress and conversation history
• Batch record processing — item results and targeted reruns
• Routine YAML reference — top-level groups and foreach structure
• Troubleshooting — interrupted runs and live status
• Usage & billing — balance checks and usage