Not every detection deserves the same response. Drift on a production connection outranks a sandbox. Recurring drift outranks a one-off. Drift in objects your changelogs own outranks drift in objects nobody tracks. The Drift Detection dashboard gives you the list; this page is how you turn it into a prioritized work queue.

Start from the dashboard signals

Open Drift Detection under Monitor and read each row against four signals:

• The Drift column: Only rows marked Drift need triage. Clean rows confirm a check ran and found nothing, which is useful coverage information but not work.

• The Database column: Each row shows the connection and its environment badge, such as Production or Staging. The environment is your first sort key.

• The Changes counts: The Added, Removed, and Modified counts show the size and shape of the drift before you open anything.

• The detection age: Each drifted object carries a first detected age on the operation's detail page. Old drift has been quietly load-bearing for longer, and anything built on top of it makes remediation harder the longer it waits.

Rank what you found

Work the drifted databases in an order you can defend:

• Environment first: A drifted production database is a live risk. The same drift in a sandbox may be someone's experiment.

• Recurrence second: Check the database's earlier drift operations. A database that drifts again after remediation has an access problem, and fixing the schema again will not hold. That pattern is worth escalating even when each individual drift is small.

• Ownership third: Drift in tables and columns your changelogs manage undermines everything you deploy on top of them. Drift in objects nothing tracks may simply be work that belongs in a changelog and has not been captured yet.

• Shape of the change last: Removed objects can break applications and deployments immediately. Modified objects, such as a changed constraint or index, alter behavior silently. Added objects are often the most benign, but they are also untracked until you capture them.

Check what is not on the list

The list only shows databases that were checked. The Database Coverage tile shows the share of registered databases with at least one drift check in the last 30 days. A database missing from the list because nothing checks it is not healthy; it is unmonitored. Rising Drift Rate across the same window means the problem is a process making out-of-band changes, not any single database.

Hand off to investigation

For each database that makes the cut, continue with Investigate detected drift. It walks from the drift flag to a remediated, verified database.