Cluster rollouts
When you change a cluster’s version, the upgrade happens without downtime and recovers on its own if it fails.
What the platform guarantees during the upgrade:
- No downtime. Your cluster keeps serving queries on its current version the whole time the new version is being brought up. Traffic only moves to the new version once it’s healthy.
- In-flight queries are protected. Queries already running when the switch happens are allowed to finish.
- A new (empty) cluster comes up directly on its first version, with nothing to switch from.
Automatic rollback (clusters)
If a cluster’s new version fails to come up, the platform automatically reverts to the version that was working before. You don’t have to do anything to recover:- The cluster ends up Running on its previous version - it does not get stuck broken or offline.
- The Activity History shows the Update as Failed.
- The cluster row shows a message noting the most recent update failed and was automatically reverted, and that the cluster is running on the previous version.
Because recovery is automatic, there is no separate “roll back” button for clusters. To intentionally move back to an earlier version, edit the cluster and select that version - it’s just a normal version change.
Platform rollout
Platform releases deploy the shared workspace components together. The deployment status progresses through:
The Platform Components section polls and updates this status in near real time while a deployment is in progress, and surfaces per-component results when a release fails.
“Not deployed” on a healthy workspace is normal. Your platform components are set up and running from the moment your workspace is created - independently of this section. The workspace keeps running on what it was provisioned with until you select and deploy a release. See What a new workspace starts with.
Platform rollback
Like clusters, a platform release rolls back automatically if it fails: if the new version doesn’t come up healthy, the platform reverts to the previous version on its own and the status shows Rolled Back. You don’t have to do anything to recover from a failed platform deploy. You can also move back to an earlier release yourself - for example, to step back from a release that deployed successfully but you no longer want:- Go to Settings → Version Upgrades and find the Platform Components section.
- In the release dropdown, select the earlier release you want.
- Select Upgrade to deploy it.
The currently-active release is excluded from the dropdown (you can’t re-deploy what’s already running), and automatically-managed releases are hidden.
Downtime expectations
For clusters, because the cluster keeps serving its current version until the new one is healthy, a failed upgrade never takes it offline - it reverts to the version that was already serving.
Failure scenarios and what to do
Operational checklist before upgrading
- Confirm the surface. Cluster version → edit the cluster; product → Version Upgrades (product rows); platform → Version Upgrades → Platform Components section.
- Check current status is steady. Don’t start an upgrade on a cluster that’s mid-deployment or failed.
- Know your rollback path. Clusters and platform releases both recover automatically if an upgrade fails; for platform you can additionally re-deploy an earlier release yourself.
- For platform changes, consider a maintenance window for anything significant.
- Watch the status through completion - Activity History for clusters, the tab status and banners for products and platform.
See also
- Status signals - where each surface reports progress.
- Zero-downtime upgrades - the cluster upgrade mechanism in depth.