# ZopDay Helm Updates: Drift Detection and Optional Rollback > ZopDay lists values changed outside Helm before an update and lets each deploy choose whether a failure rolls back automatically. Source: https://zop.dev/resources/blogs/zopday-helm-updates-drift-detection-and-optional-rollback Published: 2026-11-02 · Author: riya-mittal · Tags: cloudops, platform-engineering --- Two changes make Helm updates in ZopDay safer. Drift detection shows values that were changed outside ZopDay. The rollback option lets each deploy choose whether a failure rolls back automatically. Together they cover what happened before the update and what happens if the update fails. ## Drift Detected Lists Each Value Changed Outside ZopDay If a service's image, CPU, memory, probes or replicas were changed outside ZopDay, its Overview lists each changed value. The list shows what drifted so the team can see the difference before running an update. | What can drift | Where it appears | |---|---| | Image | Service Overview | | CPU | Service Overview | | Memory | Service Overview | | Probes | Service Overview | | Replicas | Service Overview | Each of these values can be changed outside ZopDay. When that happens, the running state no longer matches what Helm has. The Overview lists each changed value so the difference is visible before an update runs. Review and update saves the running values to Helm. Once the running values are saved, a failed update cannot roll back to an older build. The values that are actually running become the values that Helm knows about. diagram Teams managing [secrets and environment variables](https://zop.dev/resources/blogs/zopday-vm-secret-env-vars-stored-in-your-cloud-secret-manager) alongside resource values can check drift in the same service Overview. ## Roll Back Automatically if the Update Fails Every deploy, redeploy, rollback and retry confirmation has a roll-back-automatically option. It is ticked by default. Untick it to keep a failed update on the new version and debug it. | Action | Roll back option | |---|---| | Deploy | Ticked by default | | Redeploy | Ticked by default | | Rollback | Ticked by default | | Retry | Ticked by default | When the option is ticked, a failed update rolls back automatically. When the option is unticked, a failed update stays on the new version. The team can then debug the failure on the version that failed, rather than on the version that was rolled back to. Teams that manage [developer seats](https://zop.dev/resources/blogs/zopday-developer-seats-assign-now-reduce-at-renewal) at the organisation level can set the rollback option on each deploy. ## Drift and Rollback Cover Before and After Drift detection covers what happened before the update: which values were changed outside ZopDay. Review and update saves those running values to Helm. The rollback option covers what happens after the update: whether a failure rolls back automatically or keeps the new version. Teams using [role-based access controls](https://zop.dev/resources/blogs/cloud-governance-rbac-viewer-editor-admin-custom-roles) can review drift and set the rollback option on each deploy.