What a SQL Server health assessment actually checks
Most SQL Server problems are not mysteries. They are defaults nobody changed, backups nobody tested, and permissions nobody reviewed. This is what we look at, in the order we look at it, and why each one matters.
The nine areas
Every instance gets the same sweep. Findings are ranked by consequence rather than by area, so a backup gap outranks an index you could live with.
Backups and recovery
The first thing we check and the most common place we find something serious. A database with no full backup is not a performance problem, it is an existential one.
Security and permissions
Permissions accumulate. Service accounts get sysadmin because it was quicker, and nobody revisits it once the thing works.
Instance configuration
Most instances still run on defaults chosen for hardware from a different decade. These are the cheapest wins in the report — a setting change and a restart.
Memory
Left unbounded, SQL Server will take everything and starve the operating system. The symptom looks like a server problem rather than a database one.
Storage and I/O
Storage layout decisions get made once, at install, usually by whoever had the installer open. They are rarely revisited and always felt.
TempDB
A single-file TempDB on a twelve-core box will contend with itself under load. It is one of the best-known configurations in SQL Server and still one of the most commonly wrong.
Index health
Indexes are added under pressure and rarely removed. Every duplicate costs you on every write, forever, in exchange for nothing.
High availability
Plenty of instances have a recovery objective on paper and nothing configured to meet it. The gap only surfaces on the day it matters.
Patching, jobs and waits
An RTM build is missing years of fixes. A job that has failed silently for months is worse than no job. Wait statistics tell you what the instance is actually waiting on rather than what you assume.
What we usually find
These five come up on most instances we look at. None of them are exotic, and that is the point — the common failures are common because nobody has had reason to look.
Not a stale backup — none at all. Usually a database that arrived with an application install and was never added to the maintenance plan.
The log grows without bound and you are exposed to data loss beyond the last full backup. The recovery model implies a log backup schedule that was never created.
The default is 2,147,483,647 MB — effectively unlimited. SQL Server takes what it can and the operating system pays for it.
A known account name with elevated rights is the first thing anything automated tries. Named logins with least privilege cost nothing to use instead.
Unlimited parallelism means one query can commandeer every core. Microsoft's guidance is cores-per-NUMA-node capped at eight, and the default predates the guidance.
How the assessment runs
Nothing on your systems changes. The scan is read-only, needs no agent installed, and runs over a secure connection, so we work with clients anywhere.
Scoping call
Twenty minutes on what you run, how much of it, and what is keeping you up.
Read-only scan
Configuration and health data collected. No changes, no restarts, no agent left behind.
Findings report
Every finding ranked by severity with its specifics and a recommendation.
Walkthrough
We go through it with your team and agree what is worth doing first.
Common questions
Does the scan change anything on my instance?
No. It reads configuration, metadata and performance counters. Nothing is written, no service is restarted, and no agent is installed. Remediation is a separate engagement you commission afterwards, if you want it.
What access do you need?
A login with rights to read server configuration and database metadata. We tell you exactly what before you grant anything, and the account can be removed the moment the scan finishes.
How long does a SQL Server health assessment take?
The scan itself is short. The work is in reading the results properly, so the report follows within a few days of the scan rather than the same afternoon.
Do I get the report even if I do not hire you for the fixes?
Yes. The report is the deliverable, and it is written so another supplier could act on it. That is deliberate — a findings report you cannot take elsewhere is a sales document, not an assessment.
Which SQL Server versions do you assess?
SQL Server 2012 onward, on premises or on a virtual machine, plus Azure SQL Database and Azure SQL Managed Instance. Older versions can be assessed, and the age of the version is usually itself a finding.
What if the report comes back clean?
Then you have a documented baseline and something to compare against next time, which is worth having. It has not happened yet.
See what the reports look like
The sample reports were produced against a lab instance, so you can see the format and depth before you commit to anything. Or see what each report contains first.