Document why a checkpointed app can still cold start

[Hkhan161]

A customer reported a checkpoint that saved successfully but was not restored on the next scale-from-zero wake, and opened a ticket because nothing in the CLI or their logs explained it. The app was running across two compute pools, so the wake landed somewhere that held no matching checkpoint, cold started, and saved its own. That is working as designed, but it is not documented anywhere.

Adds a "When a restore does not happen" section covering:

• A checkpoint is bound to the host machine environment it was captured on, so it only restores on a matching machine.
• An app can span more than one compute pool, so the first start in a new pool cold starts and then saves its own checkpoint.
• A skipped restore is silent. The missing CEREBRIUM_RESTORED marker, or "restored": false from GET /checkpoint/status, is the only signal.

Also cross-references the new section from step 4, where the page tells readers to treat CEREBRIUM_RESTORED as the signal that a restore happened, so someone who does not see it lands here instead of assuming a bug.

Placed above the comment warning that the failure headings are anchor-linked from the checkpoint agent's error messages, so no existing anchor moved.

Made with Cursor

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
cerebrium	🟢 Ready	View Preview	Sep 17, 2026, 1:54 PM