Skip to main content
Resume a workflow from where it stopped after a crash or an interruption — without re-running steps that already finished.
This page is about workflow-step checkpoint & resume — saving how far a WorkflowManager workflow got so you can continue it. This is a different feature from workspace file checkpoints at /features/checkpoints, which snapshot files with a shadow git repo so you can undo an agent’s edits. The two systems are independent and use separate storage.
Checkpoint & resume applies to markdown workflows run through WorkflowManager.execute() / aexecute(). YAML workflows route through a different engine (AgentFlow.start()) and do not support --resume, --checkpoint, or --rebase-checkpoint yet.

Quick Start

1

Run with a checkpoint

A checkpoint is saved after each completed step.
2

Resume after an interruption

Continue from the last saved step. If you omit --checkpoint, the checkpoint name defaults to the workflow name.
The CLI prints Resumed from step N when a run continues.
3

List saved checkpoints

4

Delete when done

How It Works

Each completed step writes a checkpoint file that records how many steps are done, the results so far, the current variables, and a definition fingerprint of the workflow. On resume, the fingerprint is compared before anything runs.

Choosing Between Restart, Resume, and Rebase

After an interruption you have three options. Use this to pick one:

Definition Fingerprint

The fingerprint is a stable content hash of the workflow’s steps — the first 12 characters of a SHA-256 over each step’s name, action, agent name, and full agent config. It hashes step content, not the raw file bytes.
  • Same fingerprint for whitespace-only or comment-only edits — a resume still works.
  • New fingerprint when you add, remove, or reorder steps, or change a step’s action or agent config value (instructions, model, tools, condition, routing).
When you resume against a workflow whose fingerprint changed, the run refuses and the error names both fingerprints so you can see the mismatch:

Fail-Closed Safety

Resuming onto a checkpoint that does not exist refuses to run rather than silently starting over from step 1 and repeating side effects.

Configuration Options

Three parameters on execute() and aexecute() control this feature: A successful resume adds resumed_from_step (a 0-indexed int) to the result dict. It is absent when the run did not resume.

Checkpoint File Schema

Checkpoint files live in {workspace}/.praisonai/checkpoints/{name}.json.

Best Practices

If you run the same workflow more than once at a time, give each run a distinct --checkpoint name so they don’t overwrite each other.
Old checkpoints accumulate under .praisonai/checkpoints/. Remove one you no longer need:
After a real edit, re-running without --resume is the safe default. Only use --rebase-checkpoint when the edit was truly cosmetic and you deliberately want to continue at the same numeric step index.
A loop_over step saves a single checkpoint after the whole loop completes. On resume the loop is never re-run — execution continues from the next step.

Workflows

Build multi-step markdown workflows

File Checkpoints

Shadow-git file undo (a different feature)

Workflow CLI

The workflow run and workflow checkpoints commands

Error Recovery

Handle step failures and retries