Health check / recovery readinessPet-food manufacturer, anonymized × red9CS-0535
A health check scored one reporting server 45 of 100 and exposed the risk nobody had priced
The problem. A pet-food manufacturer asked us to look at the reporting and ETL server behind its operations. On our 145-point audit it scored 45 of 100. There was no high availability and no disaster-recovery plan, backups and corruption checks were missing, and a handful of queries were burning more than 105 hours of CPU time. One disk failure or one corrupt page would have taken the business down with no clean way back.
What we did. We ran the full 145-point health check, then handed back a report that ranked every gap by risk and effort, from the missing backups and corruption checks up front to the HA/DR design and the CPU-heavy queries behind them.
Red9 · Health Check Findings
Health-check score
45 / 100
On Red9's 145-point audit, before any remediation.
CPU time exposed
105+ hrs
Burned by untuned queries the audit surfaced.
Critical gaps found
3
No HA/DR, no tested backups, and no corruption checks.
Overall score
45 / 100
at risk
HA/DR
None in place
critical
Backups & checks
Missing
critical
Health-check score
out of 100
55-point gap
to a safe 100
Where these numbers come from. The 45 of 100 is the server's score against the 145-point checklist we run on every audit. The 105 hours is the CPU time the report attributed to a small set of untuned queries. Every figure sits in the client's own health-check report, with the fixes ordered by how much risk each one retires.
The result. The manufacturer walked away with a ranked remediation plan and a clear price tag on a risk that had been invisible. Backups and corruption checks came first, then an HA/DR design, then the CPU-heavy queries, in the order the report laid out.
The technical detail
What the audit turned up. The reporting and ETL instance had no Always On or failover cluster, no verified backup chain, and no consistency checks scheduled, while a few report queries dominated CPU to the tune of 105+ hours over the sample window.
What the report flagged first (findings summarized, identifiers withheld):
-- Red9 145-point health check: overall 45 / 100
-- P1 backups : no verified full/log chain; point-in-time recovery not possible
-- P1 integrity : DBCC CHECKDB not scheduled; corruption would go undetected
-- P1 availability : no HA/DR (no Always On, no failover cluster)
-- P2 performance : >105 CPU-hours concentrated in a handful of untuned queries
Each item shipped with the remediation step and the rollback beside it, so the client could take the critical gaps first and schedule the rest against its own calendar.