Skip to main content
Drift Actions is not enabled by default on any plan. To turn it on for your organization, contact your account manager.
Drift detection tells you which environments have drifted. Drift Actions tells you why, across your whole fleet, and lets you fix one root cause everywhere at once. A provider upgrade that drifted 40 environments is one row, not 40.

​
Where to find it

  • Organization menu > Actions > Drifts covers every project you can access.
  • Project menu > Drifts covers a single project.
The navigation item is hidden if Drift Actions is not enabled for your organization, or if you do not have the View Drift Cause permission.

​
Permissions

View Drift Cause permission:
  • Open the Drifts page and see causes
Run Apply permission on each affected environment:
  • Fix by redeploying
Edit Environment Settings permission on each affected environment:
  • Ignore and un-ignore a cause
Both actions run only on the environments you are permitted to act on. The confirmation modal reports how many were left out.

​
How causes group

A cause is identified by the destination of a change, not by the transition. A fleet mid-upgrade to aws 2.2 is one cause, whether an environment came from 2.0 or 2.1. Grouping is coarser than it looks in three cases:
  • Variable changes group on the variable, not its value. Two environments given different new values for the same variable are one cause.
  • Unmanaged changes group on the resource, not the attribute. Index segments are stripped, so aws_instance.web[0] and aws_instance.web[1] are one cause, as are a tag change in January and a security group change in March.
  • State Modified is reported only when env zero found the deployment that changed the state.
Variable values are never shown on this page. env zero does not store or serve them for this feature. A row tells you which variable changed, in which scope, and how, never what it changed to. For before and after values, open that environment’s drift detection.

​
Read the worklist

One row per cause, sorted by priority. The columns are Priority, Cause, Summary, Blast radius (environments and projects affected), Age (days since the cause was first seen, shown as <1d on the first day, hover for when it was last detected), and Actions. Filter by cause type and project, or search by subject. Expand a row for the affected environments, grouped by project, and What drifted: the commit, the provider or module and its detected version, the variable name, scope, scope ID, type and change, the resource type and path, or who changed the state and how. Five cubes sit above the worklist: Open causes, Aged over 7d, Detection enabled, Detection broken, and Median to close. Each counts only what your project access lets you see, so none of them is an organization-wide total. Detection enabled measures configuration, not coverage. An environment can have detection enabled and never have been scanned. Median to close covers the last 90 days and is a trend, not a service commitment, because env zero cannot prove what closed a cause and a cause that drifts again starts its clock over.

​
How priority is calculated

Each escalation adds at most 1, so a cause first seen 90 days ago scores the same as one first seen 8 days ago. Hover the priority badge to see the derivation for that row.
Priority is calculated per viewer and is never stored. The environment count that feeds it is narrowed by your project permissions, so two people can correctly see different priorities for the same cause.

​
Fix by redeploying

1

Select Fix by redeploying

The confirmation modal lists every environment the action will run on, and how many affected environments were excluded because you cannot deploy them.
2

Select Trigger deployments

env zero triggers a remediation deployment in each listed environment, redeploying your code so the cloud matches it.
3

Wait for detection to confirm

Deployments run asynchronously. The cause leaves the worklist once they complete and the next drift detection run confirms it is gone.
This triggers real deployments in every listed environment. There is no partial selection: the action runs on every environment in the group you are permitted to deploy. The button stays disabled until the whole batch has been sent.

​
Ignore a cause

Select Ignore on the row, then Ignore this cause in the confirmation modal. Use this for accepted drift you do not intend to fix.
Ignoring never expires and applies per environment. It does not silence the cause anywhere else, and if a new environment develops the same cause, the row returns for that environment. For unmanaged changes, ignoring is keyed on the resource, so it also hides later, unrelated changes to that resource.
To undo, turn on Show ignored and select Un-ignore. The cause reappears after the next drift detection run, about 24 hours, if the drift is still there, and its age restarts from that appearance. Environments whose settings you cannot change stay ignored.

​
When drift detection fails

If drift detection failed on its last run for any environment you can see, a banner appears above the worklist and cannot be dismissed. Those environments contribute no causes, so the worklist is incomplete by that many environments. This is a detection failure, not drift. Expand the banner to list them, up to the first 100.

​
Empty states

Drift detection is not enabled appears when none of the environments you can see are monitored. A project’s drift detection policy applies only to environments created after you enable it, so enable drift detection in each existing environment’s scheduling settings to cover it. No drift detected means env zero found no drift causes, not that every environment was scanned. Environments that have never been scanned look the same. Check the Detection enabled cube for how much of your fleet has detection turned on.

​
Next steps