Start with the gaps rather than the failures. An unchecked database produces no failures, so it never shows up when you go looking for problems.

Database Coverage and Changelog Coverage on the Policy Checks dashboard, and Database Coverage on the Drift Detection dashboard, all measure against everything registered and not archived. A low figure names a gap in what you govern rather than a quality problem, and it is the only signal that surfaces assets nobody is watching.

• Archive connections and changelogs you no longer use, so the denominator reflects what you actually run.

• Widen where your checks apply for what remains. See Define policy assignments.

On the Drift Detection dashboard, set Drift presence to Drift detected and scan the Drift column. Because Total Drift Items deduplicates per database while Drift Detected counts operations, a database that appears repeatedly is one where the same drift is being found again and again rather than being fixed. Those are the ones worth opening first.

On the Database Changes dashboard, filter by outcome and then by project to see where failures concentrate. A change failure rate that sits well above the rest of the estate in one project is usually a pipeline or practice problem rather than a run of bad luck, and Rollback Rate alongside it tells you whether those failures are being caught before or after they land.

A check that fires constantly is a cost even when every finding is legitimate. See Analyze patterns in policy failures over time for how to isolate one and decide whether it needs recalibrating.

Everything above narrows the estate to a shortlist. Taking one item through to a fix is a different job, covered in Investigate and mitigate issues. When you make a change off the back of this, decide up front which figure should move so the next window can tell you whether it did.