> ## Documentation Index > Fetch the complete documentation index at: https://www.activepieces.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Durable Execution > Interrupted runs resume from their last checkpoint instead of starting over Replay and skip: on the first attempt the trigger and step 2 are logged before the worker dies at step 3; on resume a fresh worker skips the logged trigger and step 2, re-runs the in-flight step 3, then continues fresh from step 4 Without it, a worker that dies mid-flow would restart the whole run from the trigger and re-send emails, re-charge cards, and re-call APIs. Instead, a fresh worker reuses the saved output of every finished step and runs only the first step that had not completed. The same mechanism covers crashes, deploys, long pauses, and retries. ## The run log Every flow run has a **run log**: one compressed checkpoint file with everything needed to resume the run on a fresh worker. What is in it: * One entry per finished step, keyed by step name: input (secrets hidden), output, status, duration, and the error message for failed steps. * Loop iterations and router branches use the same shape, nested under their parent step. * Run-level tags. When it is written: * Once at the start, before the first step runs. * Every 15 seconds while the run executes, from a background loop that snapshots whatever finished since the last write. * Once on the final state (success, failure, or pause). Each write overwrites the previous copy. Only the latest checkpoint is kept, and the file is compressed before upload. ## Replay and skip Resume is not a special path. Each time a worker starts a run, it walks the flow graph from the trigger and asks at every step: is this step's output already in the log? * If yes, and the step finished (`SUCCEEDED` or `PAUSED`), the engine returns the saved output and moves on. * If no, the engine runs the step, records its output, and continues. On the first run the log is empty, so every step runs. After a resume the log is full up to the interruption, so the engine skips through all of it and runs only what came next. The most a crash can lose is the single step that was running when the worker died. That step runs again from the last checkpoint, and everything before it is skipped. ## What triggers a resume Every interruption resolves through the same replay path. Only the trigger differs. * **Worker crash or deployment.** The queue reassigns the run to another worker, which loads the log and replays. * **Paused step.** The piece creates a [waitpoint](/docs/install/architecture/waitpoints). When the waitpoint fires, a resume job is queued and a worker replays the run. * **Retry from a failed step.** The same log is reused. The run is re-queued and a worker replays from the failure point. * **Normal progression within one worker.** Same replay model, without leaving the process.