Saturation and blocking stormIndustrial equipment manufacturer, anonymized × red9CS-0385
An over-capacity server kept serving through 326 blocking alerts in one month
The problem. An industrial equipment manufacturer's main instance went past its own capacity line. SQL usage, the client's own capacity metric, jumped 62% month on month to 113.31%, past the line where demand outruns the instance. SQL errors rose 357% to 48,466, permission-denied failures were flooding one database, and blocking queries had turned into a storm rather than an incident.
What we did. We worked the surge instead of theorizing about it. 349 alerts came through that month, up 157%, and every one was handled: 326 P2 blocking-query alerts, along with high-CPU alerts and an SSL expiry warning that would have caused an outage of its own. Each blocking event was recorded with the statement behind it, so the tuning backlog came out of evidence rather than opinion, and the permission errors went to the team whose code was generating them.
Red9 · Managed Services Month
Blocking alerts worked
326
All P2, inside one month, on a saturated instance.
SQL usage
51% → 113%
Past the capacity line the server is rated to.
Total alerts handled
349
Up 157% on the prior month, including an SSL expiry warning caught early.
SQL usage
51.06% → 113.31%
over capacity
Blocking alerts
326 P2
all handled
Service
Held through the surge
no outage
Blocking alerts
share of the month's 349
Where the numbers come from. Every figure is from the client's monthly managed-services report: the SQL usage readings of 51.06% and 113.31%, the 48,466 error count, and the alert breakdown that gives 326 P2 blocking alerts out of 349 handled. The usage number is stated as found, because this month is a capacity story rather than a tuning win.
The result. The manufacturer kept trading on a server that had run out of headroom, which was the objective that month. It also finished with a ranked tuning backlog built from 326 recorded blocking events and a clear separation between the faults that belonged to the database and the ones that belonged to the application.
The technical detail
What the month showed. On that metric anything above 100% means demand has outgrown the instance, and blocking is the usual first symptom: statements queue, waits compound, and the alert count climbs faster than the workload does. The 357% error rise was largely permission-denied noise from one database, which inflates the count without indicating a database fault.
How the month was worked (findings summarized, identifiers withheld):
-- Managed services month, SQL Server 2022 instance
-- capacity : SQL usage 51.06% -> 113.31% (over the 100% line)
-- P2 x326 : blocking queries; each captured with the offending statement
-- P2 other : high CPU alerts; SSL expiry warning caught before it lapsed
-- errors : 48,466 total, dominated by permission-denied in one database
-- output : ranked tuning backlog + capacity case, evidence attached
Nothing here was fixed by tuning alone. The month bought time and produced the evidence for the capacity decision that followed.