What a SQL Server Health Check should cover

Ardentech Solutions Inc. · ardentechsolutions.com · Last reviewed October 25, 2026

A good health check looks at four things together and ends with a ranked list you can act on. Here is what good looks like in each, and what to ask for.

Why four areas, together

A problem in one area often shows up in another. A slow query becomes a slow report. A missed backup becomes an outage you cannot recover from. A loose permission becomes an audit finding. Looking at all four together is how you see the real risks.

Performance

Slow applications and reports are the symptom people notice. A good review finds the cause.

What to look for

• Slow or expensive queries.
• Missing, unused, or badly maintained indexes.
• Blocking and deadlocks.
• Pressure on CPU, memory, or storage.
• Instance settings that do not suit the workload.

Good looks like: You know what normal looks like, the heaviest queries are identified, and there is headroom for growth.

Availability

This is about how your databases stay up, and what happens when something fails.

What to look for

• How failover is set up: clustering, availability groups, or recovery from backups.
• Single points of failure: one server, one disk, one network path, or one person who knows how it works.
• Whether failover has ever been tested.
• How long recovery would really take, and how much data you could lose.
• Alerting, so someone knows when something fails.

Good looks like: The downtime and data loss the business can accept are agreed, and the setup has been tested against them, not assumed.

Backups

A backup is only worth something if it can be restored.

What to look for

• Backups running on schedule and monitored.
• Retention that matches business and legal needs.
• Copies stored away from the server itself.
• Restores that have been tested, not just backup jobs reporting success.
• Log backups where you need to restore to a point in time.

Good looks like: You can name the last time you restored a backup, and how long it took.

Security

This covers who can reach your data, and what an audit or security review would ask.

What to look for

• A supported, patched SQL Server version.
• Who has high-level (sysadmin) access, and whether they still need it.
• Shared or default accounts.
• Service accounts and the permissions they hold.
• Encryption where it is required.
• Auditing and logging.
• How the server is exposed on the network.

Good looks like: Access is limited to what each person needs, and you could answer an auditor's first questions.

What a good report looks like

• A ranked list, so you know what to tackle first and what can wait.
• Each finding says why it matters and roughly how much effort the fix takes.
• Quick wins are separated from larger projects.
• A plain-language summary that a non-technical leader can read.
• Nothing in your environment is changed without your agreement.

Questions to ask any provider

• What access do you need, and how will it be limited?
• Will you change anything during the review?
• How do you rank your findings?
• Is the report mine to keep and act on, with or without you?
• How long will it take?

This page is general guidance based on common SQL Server administration practice. Every environment is different, so use it to ask better questions rather than as a substitute for a review.