Rollback changes which previously processed deployment serves a site. It is useful when a newly published website has broken content, navigation, assets, or behavior and a known good version is available.
Inspect the current release#
Start with the correct organization and site. Call list_sites to inspect the current site and release configuration, then list_deploys for recent deployment IDs, sequences, statuses, environments, timestamps, and Git metadata.
A deployment ID is a global deployment identifier. A sequence identifies a version within that site; the rollback tool uses to_sequence.
For a workflow with independent destinations, note which deployment is staged and which is production. The newest deployment is not necessarily the production release.
Choose a known good version#
Use an earlier version whose public behavior was verified. Compare its timestamp, source commit where available, and release notes with the problem you are recovering from.
A candidate must have previously gone live or be an eligible rolled-back version. An uploaded or failed artifact that never became live is not a recovery target.
Ask your agent to explain the selected site, environment, current sequence, and proposed recovery sequence before acting when the recovery destination has not already been authorized.
Run the rollback#
Call rollback with the selected organization, site slug, sequence, and environment:
{"organization_id":42,"site_slug":"example-site","to_sequence":12,"environment":"production"}
The example values are illustrative. Use the values discovered in the site's history. Rollback accepts staging or production; it is not a combined both operation. Staging requires an active release workflow.
The response identifies the selected environment, current sequence, and public URL. Inspect it, then open that URL rather than assuming that the control-plane response establishes the complete visitor experience.
Verify recovery#
Check the specific broken page and a representative set of links, assets, and important visitor actions. Confirm the expected content appears in the raw HTML and test chat when its behavior was affected. For independent releases, inspect the other destination to confirm its intended state.
Rollback selects an older deployment; it does not reverse source commits, external service changes, organization settings, or every subsequent CMS operation. Verify article content and shared widget settings separately. Keep the current editable source and fix the underlying cause there before the next deployment, or the next build may reintroduce the same defect.
If no suitable deployment is visible or a rollback fails, preserve the error, site identity, environment, and intended sequence and contact support. Do not recover by creating a new site with a different URL. See deployment troubleshooting for artifact-level failures.