Checkpointing is in early release. APIs may change in future versions.
Overview
Checkpointing automatically saves execution state during a run. If a crew, flow, or agent fails mid-execution, you can restore from the last checkpoint and resume without re-running completed work.
Quick Start
Checkpoint files are written to ./.checkpoints/ after each completed task.
Configuration
Use CheckpointConfig for full control:
CheckpointConfig Fields
Inheritance and Opt-Out
The checkpoint field on Crew, Flow, and Agent accepts CheckpointConfig, True, False, or None:
Resuming from a Checkpoint
The restored crew skips already-completed tasks and resumes from the first incomplete one.
Works on Crew, Flow, and Agent
Crew
Default trigger: task_completed (one checkpoint per finished task).
Flow
Agent
Storage Providers
CrewAI ships with two checkpoint storage providers.
JsonProvider (default)
Writes each checkpoint as a separate JSON file. Simple, human-readable, easy to inspect.
Files are named <timestamp>_<uuid>.json inside the location directory.
SqliteProvider
Stores all checkpoints in a single SQLite database file. Better for high-frequency checkpointing and avoids many small files.
WAL journal mode is enabled for concurrent read access.
Event Types
The on_events field accepts any combination of event type strings. Common choices:
Using ["*"] or high-frequency events like llm_call_completed will write many checkpoint files and may impact performance. Use max_checkpoints to limit disk usage.
Manual Checkpointing
For full control, register your own event handler and call state.checkpoint() directly:
The state argument is the RuntimeState passed automatically by the event bus when your handler accepts 3 parameters. You can register handlers on any event type listed in the Event Listeners documentation.
Checkpointing is best-effort: if a checkpoint write fails, the error is logged but execution continues uninterrupted.