Replaying from the UI
- From a run
- Runs list
1
Click the Replay button in the top right

2
Confirm replay settings
You can edit the payload (if available) and choose the environment to replay the run in.

Detecting replays in your task
You can check if a run is a replay using the context object:Replaying using the SDK
You can replay a run using the SDK:Your backend code
Your backend code
trigger() options: payload, metadata, tags, queue, concurrencyKey, machine, version, region, delay, ttl, idempotencyKey, idempotencyKeyTTL, maxAttempts, maxDuration, and priority. If you leave out payload, metadata, tags, queue, concurrencyKey, or machine, the new run uses the original run’s value. The other options fall back to the task’s current defaults, and without version the replay runs on the current version. The replay always runs in the same environment as the original run.
A queue must already exist in the environment, and a version must be a version deployed to it. Otherwise the replay fails with an error and no run is created.
A replay starts a new run, so the API key or token you replay with needs permission to trigger the task as well as write access to the run.
The SDK serializes a payload override the same way trigger() does, so values like Date, BigInt, Map and Set reach the task with their types.
When you call trigger() or batchTrigger() on a task you receive back a run handle which has an id property. You can use that id to replay the run.
You can also access the run id from inside a run. You could write this to your database and then replay it later.



