SQL Server Health Checks: What a Proper Review Covers

Most SQL Server health checks are a disappointment. Someone runs a script, exports a report, and hands over forty pages of green and amber traffic lights that nobody on your team knows how to act on. You paid for reassurance and got a PDF.

A proper health check is different. It's a structured review of the whole platform, not just query performance, but configuration, backup integrity, security posture, capacity headroom, indexing, and the job schedule that keeps everything running quietly in the background. Each area should produce specific findings tied to specific risks, not a generic score.

This matters more than most SME leadership teams realise. SQL Server rarely fails suddenly. It degrades, a job that silently stops running, a backup that hasn't been tested in a restore, a disk that's 91% full and climbing. A good health check catches these before they become incidents. A bad one just tells you what you already knew.

This article sets out what should be on the checklist when you commission one, whether you're doing it as a one-off sanity check or as the entry point into ongoing managed database administration.

Why health checks get commissioned

There are usually three triggers:

• Something went wrong. A slowdown, an outage, or a near-miss that made leadership ask "how exposed are we?"
• Someone left. The person who understood the database estate has gone, and nobody is confident about what's actually running.
• Due diligence. An acquisition, a compliance requirement, or a board asking for assurance on data infrastructure risk.

In all three cases, the value isn't the report, it's the decisions the report enables. That's why scope matters more than length.

The seven areas a proper review covers

1. Performance

This is the area everyone expects, and it's necessary but not sufficient on its own.

• Query wait statistics over a representative period, not a five-minute snapshot
• Top resource-consuming queries and whether they're improving or worsening over time
• Memory pressure, CPU pressure, and tempdb contention
• Blocking and deadlock frequency

A one-off performance snapshot taken at 3pm on a Tuesday tells you very little. If you're seeing recurring slowdowns, it's worth reading our piece on diagnosing SQL Server performance issues alongside the health check itself.

2. Configuration

Default settings are rarely right for a production workload years after go-live.

• Max server memory, parallelism settings (MAXDOP, cost threshold), and instance-level settings
• Database-level settings: recovery model, autogrowth configuration, compatibility level
• tempdb file configuration and placement
• Alignment with current Microsoft best practice, not the best practice from the version this was originally installed on

3. Backup and disaster recovery

This is the section that most exposes risk, and the one most often skipped or done superficially.

• Backup schedule versus actual recovery point objective (RPO) the business needs
• Whether backups are being tested with actual restores, not just verified as "completed successfully"
• Log backup frequency and log file growth behaviour
• Failover configuration if applicable, and when it was last tested

A backup you haven't restored is a theory, not a safety net.

4. Security

• Login and permission audit, who has sysadmin, and why
• Service account configuration and privilege level
• Encryption status for data at rest and in transit where required
• SQL Server version and patch level against currently supported builds

5. Capacity

• Disk space headroom on data, log, and tempdb volumes, with growth trend
• CPU and memory trend over the past 6–12 months, not just current utilisation
• Database file growth patterns and whether autogrowth events are causing fragmentation

6. Indexing and maintenance

• Missing index recommendations weighed against existing index overlap
• Index fragmentation and whether maintenance jobs are actually addressing it
• Statistics update frequency and whether auto-update thresholds fit the data volume

7. SQL Server Agent jobs and scheduled tasks

• Full inventory of scheduled jobs, what they do, and who owns them
• Job failure history, not just "is it currently enabled" but "has it actually been succeeding"
• Overlapping or redundant jobs that were never cleaned up after a migration or upgrade

This is one of the most commonly overlooked areas. Jobs fail silently far more often than dashboards suggest, and the business impact usually surfaces somewhere unrelated, weeks later. It's the same pattern we cover in why data pipeline failures don't always announce themselves.

What a good health check report actually contains

If your last health check looked like the left-hand column, it wasn't a health check, it was a scan.

Who should be doing the check

Internally, this is hard to do well precisely because the person best placed to run it is the person closest to the environment, and proximity creates blind spots. An external reviewer with no stake in the existing configuration will ask the uncomfortable questions your own team has stopped asking.

This is also why health checks are a natural entry point for managed database administration, rather than a one-off engagement. A single check tells you where you stand today. Ongoing oversight tells you when something starts drifting before it becomes the next incident. If you're weighing up whether to bring in external support at all, our comparison of when to outsource database administration sets out the trade-offs plainly.

What it costs to skip this

Teams that defer health checks tend to discover problems reactively, usually at the worst possible moment. We've written separately about the real cost of reactive database support, and the pattern is consistent: the incident that triggers an emergency call was visible in the configuration months earlier.

Get a proper review, not a scan

If you want a clear, evidence-based picture of where your SQL Server estate actually stands, not a traffic-light PDF, our SQL Server Data Platform Audit covers all seven areas above, with findings ranked by business risk and a practical remediation plan attached to each one.

Get the SQL Server health check guide and get a straight answer on where your platform stands before something forces the question.