SQL Server rarely fails without warning. If you're seeing any two of the seven signs below, your environment is past due for a health check. Each one is cheap to ignore for a while — and expensive when it tips over.
Most production outages I'm called in to help with were preventable months earlier. The warning signs were there; nobody had time to look. Here are the seven I see most often — in rough order of urgency.
1. Your morning starts with "the database is slow"
If users routinely report sluggishness in the first hour of the workday, that's almost never a coincidence. Common root causes: statistics auto-updates kicking in at the start of business, plan cache evictions overnight forcing first-time recompiles, or backup/index-maintenance jobs running too close to the work window. None of these are obvious from a tool report — they show up in when the waits occur, not just which waits.
2. Wait stats are climbing month over month
If you're tracking wait stats at all (and you should be), watch the slope. A 20% month-over-month increase in PAGEIOLATCH_*, CXPACKET, or LCK_M_* waits is a leading indicator months before users feel it. By the time wait time per batch request crosses a perceptible threshold, you're already in the danger zone.
3. tempdb is growing and you don't know why
tempdb file sizes that climb without explanation usually mean one of three things: a runaway query holding a version store, a poorly written batch process that spills hash joins, or an application using temp tables as a working set. All three are diagnosable. None are normal.
Run SELECT SUM(unallocated_extent_page_count)*8.0/1024 AS free_mb FROM sys.dm_db_file_space_usage and watch it across a workday. If it climbs and never comes back down, something is leaking.
4. You haven't tested a restore in 6+ months
A backup is a file. A restore is a recovery. If nobody on the team has actually performed a full restore of a production-scale database to a test environment recently, you have backups, not a recovery plan. This is the single highest-leverage thing a health check surfaces — and the one most teams ignore until they can't.
5. Your last SQL Server upgrade is one or two versions behind
SQL Server 2016 mainstream support ended in 2021. SQL Server 2017 ends in 2027. SQL Server 2019 ends in 2030. Running on unsupported or end-of-mainstream versions means you're missing performance fixes, security patches, and modern feature options (Query Store changes, intelligent query processing, accelerated database recovery). A health check tells you what you'd gain by upgrading and what the migration path looks like.
6. You have an upcoming audit — SOC 2, HIPAA, PCI-DSS, or DoD STIG
Auditors don't ask "is your database fast?" They ask: are sysadmin accounts justified? Is TDE enabled? Are audit logs retained? Are connections encrypted? Are patches current? A health check produces the documentation evidence auditors look for, in the format they expect — not a panicked scramble two weeks before the deadline.
7. You're planning a cloud migration
Migrating an unhealthy database to Azure SQL or AWS RDS is the most expensive way to find out it was unhealthy. Pre-migration health checks consistently save 3–6x their cost in avoided cloud overprovisioning. Here's why — in detail.
None of these on its own is fatal
The point isn't that any single sign means disaster. It's that they tend to cluster. If you saw yourself in two or more, that's the signal.
A free 20-minute discovery call below tells us both whether a health check is the right next step — no pressure, no commitment.