Drift detection compares what is actually running, including cloud resources, server settings or DNS records, with what your code or template says should exist. Any difference is reported as drift.
Why it matters
Manual changes are inevitable during incidents. Without detection they become permanent surprises that surface during a rebuild or an audit. Regular checks turn an invisible problem into a ticket. The same idea applies outside servers: monitoring DNS records, TLS certificates or HTTP security headers for unexpected change catches misconfiguration and some kinds of tampering.
Example
With Terraform, a plan shows differences between code, state and reality:
terraform plan -refresh-onlyA line such as ~ aws_security_group.web ingress changed outside of Terraform indicates someone edited the rule manually. Run it on a schedule in CI and send a notification when the exit code or output shows changes. For DNS, a monitor that alerts when a nameserver or MX record changes serves the same purpose.
Common mistakes
- Detecting drift but having no policy on whether to revert it or adopt it into code.
- Running checks so rarely that the drift is months old.
- Ignoring resources outside the tool's scope, like manually created DNS records or forgotten test servers.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.