Skip to main content
Rollback moves the published pointer backward. New runs use the older version; in-flight runs finish on whatever they started with. Rollback is:
  • Instant — a pointer update, not a redeploy. Seconds.
  • Atomic — the whole Flow rolls at once. No partial state.
  • Reversible — you can roll forward again, or to any other version.
  • Auditable — logged with actor, reason, timestamp.

​
When to roll back

  • Signals spike immediately after a publish.
  • A regression was caught late (not by simulation).
  • A downstream dependency broke and the fix takes time — rolling back buys time.
  • A canary rollout is misbehaving.
The cost of rolling back is very low. Roll back sooner rather than later.

​
How to roll back

​
From the app

Flow → Versions → pick a prior version → Rollback. Confirm with a reason.

​
From the CLI

Version ID is the short hash (or the version number, e.g., v14).

​
From a webhook (auto-rollback)

Configure per Flow: Flow settings → Auto-rollback.
  • Trigger on: signal rate > threshold, error rate > threshold, cost per run > threshold, canary metrics diverge.
  • Rollback target: previous version, or a specific pinned “safe” version.
  • Notify: Slack channel, on-call PagerDuty.
Auto-rollback engages only for the specific trigger and Flow you set it on — it doesn’t roll back proactively.

​
What rolls back

Everything in the version:
  • Prompts.
  • Wired connections.
  • Tool configs and secrets.
  • Settings and limits.
  • Attached preset versions.
  • Attached data source versions.
Nothing that lives outside the Flow version rolls back:
  • Documents in your knowledge base (unless the version pinned specific document versions).
  • Memory items written since the earlier version was live.
  • Traces (they’re per-run and stay attached to the version that ran).

​
After rollback

  • Draft is untouched. If you want the rolled-back version to become your new working base, use Restore Draft from version (see Drafts).
  • Signals that were opened against the newer version stay open, tagged with the version that produced them.
  • Improvement history shows the rollback as a distinct entry.

​
Rollback vs. restore-draft

Two different actions:
  • Rollback — production pointer moves. Draft unchanged. Production runs the older version. Reversible.
  • Restore Draft from version — Draft is replaced with an older version’s contents. Production unchanged (still on whatever version is currently pointed to). You can then edit and publish anew.
Use rollback for emergencies. Use restore-draft when you want to hand-modify an older version into a new fix.

​
Rollback of a specific Improvement

If you know which Improvement caused the issue, rollback the Improvement rather than the whole version: Optimization → History → Improvement → Rollback. This is finer-grained than a version rollback — it undoes just that Improvement’s changes, keeping subsequent improvements intact. Works only if no later improvement conflicts with the one being rolled back.

​
Audit

Every rollback is logged with:
  • Who initiated it.
  • Which version rolled from → to.
  • The reason (mandatory).
  • Whether it was manual or auto-triggered.
Exportable for compliance.