Re-run Any Workflow Execution from a Chosen Task

For the complete documentation index, see llms.txt. For a full content snapshot, see llms-full.txt. Append .md to any kestra.io/docs/* URL for plain Markdown.

Replay re-runs a workflow execution from any chosen task, skipping tasks that already completed successfully. Use it to recover from failures without reprocessing upstream tasks, or to iterate on a specific task without re-running the full flow.

To replay from a specific task, open the Gantt or Logs tab of any execution and use the three-dot menu on the task run. You can also replay a single execution or bulk-replay from the Executions page, with the option to use the latest flow revision.

To replay all missed schedule intervals in a time window instead, see Backfill.

Example: fixing a failed task and replaying

Consider a flow that downloads a file and then validates its schema:

id: replay_demo
namespace: company.team
tasks:
- id: download
type: io.kestra.plugin.core.http.Download
uri: https://huggingface.co/datasets/kestra/datasets/raw/main/csv/orders.csv
- id: validate
type: io.kestra.plugin.core.execution.Assert
errorMessage: "Schema validation failed — unexpected number of columns"
conditions:
- "{{ 8 >= 5 }}"
- id: notify
type: io.kestra.plugin.core.log.Log
message: Validation passed, data is ready for processing.

Run the flow once with 8 == 5 as the condition. download succeeds, then validate fails because the assertion is always false.

Open the failed execution and go to the Gantt tab. Use the three-dot menu on validate to select Fix with AI, or correct the condition yourself: change 8 == 5 to 8 >= 5 and save as a new revision. Then select Replay from the same menu.

Gantt tab of a failed execution showing the three-dot menu on validate with Fix with AI and Replay options

In the confirmation dialog, select Latest flow revision to use the revision containing your fix.

Replay execution dialog showing revision options: Original flow revision, Latest flow revision, and Specific flow revision

The download task is skipped; Kestra reuses its output from the original execution. Only validate and notify run again. The Attempt 2/2 label on validate confirms this is the replayed run.

Gantt view of the replayed execution showing download skipped, validate with Attempt 2/2 succeeding, and notify running

The Overview tab shows the attempt number, the revision used, a system.replay: true label marking this as a replay, and a system.correlationId label linking back to the original execution.

Overview tab showing Execution is Replayed badge, system.replay: true label, 2 revisions, 2 attempts, and a link to the original execution

Replay on another flow revision

When you replay from a task run on the Latest flow revision or a Specific flow revision, Kestra reuses the stored results of the tasks before the one you replay from. The original revision produced those results, so Kestra first checks that the chosen revision would have produced the same results, and refuses the replay otherwise.

Compared with the revision the execution ran on, Kestra refuses the replay when:

  • a task before the one you replay from changed, was renamed, was removed, or had a task inserted in front of it (Flowable tasks are compared recursively; Kestra ignores changes to description, retry, timeout, workerSelector, allowFailure, and allowWarning)
  • an input was removed, changed type, or lost its default value.
  • a variable was removed or changed.

You can still edit the task you replay from, any task after it, and any task that never ran. Replaying on the original revision, or replaying a whole execution without selecting a task run, needs no check because nothing is reused.

The replay dialog runs the check as soon as you pick a revision and shows the result before you confirm. When the check fails, the confirm button is disabled and the dialog shows the reason. Select Replay the whole execution instead to keep the chosen revision and run every task again. Kestra keeps and links the original execution, as with any replay.

The API exposes the same check. POST /api/v1/{tenant}/executions/{executionId}/actions/replay/validate takes the taskRunId and revision query parameters and returns 200 when the replay is possible, or 409 with the reason when it is not.

What the check cannot tell

Kestra compares flow definitions. A passing check does not make a replay on another revision deterministic, because the results of the tasks after the chosen one can still depend on things outside the flow:

  • secrets, which Kestra reads on every call and which may have been rotated or expired
  • file inputs and non-interactive inputs, which may have changed since the original run
  • Pebble expressions that call external systems, which may return different values today

Was this page helpful?