Performing your first rollback

A rollback restores an application to one of its captured snapshots. The in-cluster controller re-applies the manifests that the snapshot holds, in dependency order, and returns the rollback record once the apply phase finishes.

Pick a snapshot

List the snapshots for an application:

GET /v1/applications/{name}/snapshots

Each snapshot has an id, the change class that produced it, a captured-at timestamp, and the list of manifest kinds covered.

Trigger the rollback

POST /v1/applications/{name}/rollback
Content-Type: application/json

{
  "snapshot": "snap_2026-05-17T08:42:11Z",
  "reason":   "config drift on payments"
}

The API returns immediately with a rollback id and a pending status. Poll the rollback resource until it reaches restored or failed.

Verify

When the rollback reports restored:

• The application generation is incremented.
• A change cycle of class rollback is recorded with severity informational.
• A fresh snapshot is captured of the restored state, so the next rollback target is the post-restore baseline.

If the controller fails to apply any manifest, the rollback record stops at failed and the partial state is left untouched.