Guides / Deployment Drift: Detect It in GitHub Actions

Deployment Drift: What It Is and How to Detect It in GitHub Actions

Published 2026-09-04 · by the ShipGlance team at Last Ridge

Deployment drift is the gap between the commit running in an environment and the commit at the head of the branch that feeds it. It appears when code merges but no deploy runs, so every check stays green while production quietly falls behind. Detecting it means comparing the deployed commit with the branch head for every environment, continuously, and saying "unknown" when you cannot.

What is deployment drift?

Production is on one commit. main is seven commits ahead. Nothing on any screen says so, because every workflow that ran has passed. That gap is deployment drift, sometimes called deploy drift or environment drift. It is a property of two commits, not of a run, and it is invisible to any tool that only lists runs.

Why does deployment drift go unnoticed?

• CI reports on runs. A run passed or failed. Drift changes when nothing runs at all: a merge lands, the deploy workflow is manual, scheduled, or gated, and the environment falls behind without a single red X.
• The signal is spread out. The deployed commit lives in one place and the branch head in another. Nobody compares them by hand on a Tuesday afternoon.
• The symptom arrives late. It surfaces as "but that fix merged days ago", usually reported by a customer.

Teams shipping with AI coding agents see this more, not less. Agents merge small changes often, deploys stay human-gated, and the gap between "merged" and "live" becomes the normal state rather than the exception.

How do you detect deployment drift in GitHub Actions?

Deployment drift detection needs two facts per environment:

1. The deployed commit. The commit of the most recent successful run whose job targeted that environment. In GitHub Actions, a job that declares an environment is the signal.
2. The branch head. The current tip of the branch the deploy workflow runs from.

If the two are equal, the environment is up to date. If they differ, the commits between them are what is waiting to go out, and the files they touched tell you whether anyone should care. The requirement is to re-evaluate on every push, not on a schedule, because drift begins the moment a merge lands.

What are the three states of deployment drift?

The most common mistake is rendering drift as a boolean. There are three states:

• Up to date: both commits known and equal.
• Drifting: both known and different; show the commit count and the changed paths.
• Unknown: it could not be evaluated. No successful deploy on record, the comparison failed, or access was missing. This must render as unknown, never as "up to date". A calm state you cannot prove is the exact failure mode drift detection exists to remove.

Which commits should count as drift?

Not every commit needs a deploy. A README change on main does not mean production is behind in any way anyone cares about. Good drift detection lets each pipeline declare which paths count, so a docs-only commit does not page anyone and a change under the service's source directory does.

What should you alert on when drift appears?

Alert on the transition into drift, once, with the commit count and a link to the comparison. Do not alert on every commit while drifting; the team already knows. Clear the alert when the deploy lands. See deploy alerts to Slack without the noise.

How does ShipGlance detect deployment drift?

Drift is one of the four questions a GitHub Actions deployment dashboard must answer. ShipGlance evaluates it per environment on every push, renders all three states honestly, and lists the commits and paths in the gap, across every repository your team ships from.

• Install the read-only GitHub App; see the quickstart.
• Environments declared in your workflows become drift lanes with no extra YAML.
• See pricing or request early access.