Quick Scan
Overview
The Quick Scan runs 156 checks across an instance and answers the question a DBA opens it to ask: is this instance in reasonable shape.
What this replaces
The page used to be a bare list view. The scan ran its 156 checks over six connections and then printed the answers into seven columns with no colour at all. The [RED]:, [YELLOW]: and [GREEN]: prefix handling in the code had never once fired, because no check in QuickScanDetails.xml emits those prefixes.
Sorting was Urgent first, then alphabetical on a Type column that mixed categories with severities, then Issue ID compared as text, so check 10 sorted above check 2. Nothing on the page answered the shape-of-the-instance question; it answered only “here is a list”.
The grid was also the only place any of the data lived, and every action read it back by sub-item index: SubItems(2) for the message, SubItems(3) for the URL, SubItems(4) for the issue number. That is why the columns could never be reordered. Each row now carries its finding as an object and the indexes are gone.
Where to find it
| Route | How |
|---|---|
| Server tree | Right-click the server → Instance Reports → Quick Scan |
Requirements
- Permission to read the instance-level catalog and DMVs the checks use. Checks that cannot run report themselves as failed rather than passing silently.
- The scan opens six connections and runs 156 checks, so it is not instant.
Reading the band
The score
One number, and the first thing on the page. It is a weighted pass rate over every check that ran, not only over the ones that found something.
That distinction is the whole design. Two critical findings among a hundred and fifty clean checks must not round up to “fine”, and a score computed only over findings would do exactly that.
The severity tiles
Four counts, and the page’s primary filter:
| Severity | What it means in practice |
|---|---|
| Critical | Act tonight. |
| High | Act this week. |
| Medium | Schedule it. |
| Low | Know about it. |
They are separate tiles rather than one stacked bar precisely because they are what you filter by. Two criticals is a number somebody acts on tonight; forty low severity findings is a number somebody schedules. Those two want to be one click apart.
The category bars
The 156 checks already divide ten ways, and the old report threw that division away:
| Category |
|---|
| Corruption and Integrity |
| Backup and Recovery |
| Storage and Files |
| Availability and Replication |
| Configuration |
| Performance |
| Agent |
| Security |
| Error Log |
| Maintenance |
“Backup and Recovery is where this instance is weak” is a more useful sentence than any single finding, and it is the sentence the bars say.
Reading the grid
| Column | What it carries |
|---|---|
| Severity | Critical, High, Medium or Low. |
| Category | One of the ten above. |
| Check | The name of the check that fired. |
| Finding | The one line the check wrote about this particular object. |
| Est. | Estimated hours to address, where the check offers one. Blank where it does not. |
| Issue | The issue number, which is what the online article is keyed on. |
| Assigned To | Who is carrying it, where that has been set. |
Est. is deliberately blank rather than zero where a check gives no estimate. Zero hours and no opinion are different claims.
Findings about the scan, not the instance
Some rows are not findings about your server at all. When a check cannot run, the outer error handler produces a row marking that check as having failed. Those are findings about the scan, and they are kept distinct rather than being counted as passes.
That matters for the score: a check that could not run has not passed, and quietly treating it as one would inflate the number in exactly the situation where you should trust it least.
How to read the report
- Read the score. It is the summary and it is weighted over every check, so it is not gameable by having few findings.
- Look at the severity tiles before the grid. If Critical is zero, tonight is fine regardless of what the total count says.
- Click Critical and work that list to empty.
- Then read the category bars. A tall bar is a theme, and a theme is usually one decision rather than several fixes.
- Use the Issue number to reach the article behind a check when the one-line finding is not enough.
- Rescan after changes. The score is the fastest way to confirm a change landed.
Common patterns
A high score with two criticals. The score is doing its job. Most of the instance is fine and two things are not. Fix those two.
One category bar far taller than the rest. A theme rather than a list. Backup and Recovery weak usually means one job or one policy, not fifteen separate mistakes.
Many findings, all Low. Housekeeping. Schedule it; do not let it crowd out the criticals.
Rows saying a check could not run. A permission problem, not a clean instance. The score already accounts for it, but these are worth clearing so the next scan means more.
Where the data comes from
The checks are defined in QuickScanDetails.xml, and their names, descriptions, severities, categories and effort estimates come from the shipped catalog rather than from the server. The findings themselves come from the instance.
Nothing is stored and nothing is written. Every finding is produced fresh by a scan.
Related reports
| Report | Why you would go there |
|---|---|
| Security Posture | The security surface in depth, rather than as one category. |
| Backup Status | Whether the Backup and Recovery findings are as bad as they read. |
| Last DBCC CheckDB Known Good | The corruption category’s most important single fact. |
| Migration Planner | The forward-looking version of the same audit instinct. |
| Failed Jobs | Where Agent findings usually originate. |
Frequently asked questions
What is the score, exactly? A weighted pass rate over every check that ran. Not a percentage of findings, and not a count.
Why is my score not 100 when I have no critical findings? Because Medium and Low findings still weigh on it, and because a check that could not run does not count as a pass.
Why is the Est. column blank? That check offers no estimate. Blank and zero are different claims, so it does not print a zero.
What are the rows that say a check failed? Findings about the scan rather than about the instance, usually a permission the login does not have. They are kept separate on purpose.
Can I reorder the columns now? Yes. Each row carries its finding as an object rather than the actions reading it back by sub-item index, which is what used to freeze the column order.
How long does it take? It runs 156 checks over six connections, so it is not instant. It is a scan rather than a live page.