Skip to main content
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.