Portrait of Mihaly KerteszMihaly KerteszSQL Server consulting

sql server / case study

Monitoring Gaps Review

The SQL Servers had monitoring. The problem was that the signals were not useful enough.

A SQL Server case study about monitoring that existed on paper but still missed the signals the team needed under pressure.

Technical evidence checked

Alert review

SQL Agent operators, alerts, failed-job notifications, severity 17-25 handling, Database Mail health, and who received each signal.

Coverage checks

Backups, CHECKDB, disk free space, long-running jobs, blocking visibility, deadlock capture, and error-log scan coverage.

Baseline data

Recent wait snapshots, CPU and memory pressure indicators, file growth events, backup duration trends, and job runtime history.

Gap found

Several alerts reported activity, but did not separate urgent operational risk from routine noise. That is a signal-quality problem, not a tooling problem.

Fact-check note

The page avoids naming a monitoring product because the technical issue is independent of the tool. The same failure pattern can happen in SQL Agent, third-party tools, or custom dashboards.

Case snapshot

The SQL Server environment already had monitoring in place, which made the problem harder to discuss. Dashboards existed, alerts fired, and jobs produced status. From a distance, it looked covered.

The team still did not trust it. Incidents were being noticed through users, delayed application symptoms, or someone checking manually after the fact. The monitoring stack was present, but the operating picture was soft.

Tooling had been mistaken for visibility. The real question was whether the signals helped the team make a good decision during a bad hour.

ItemDetail
Environment typeSQL Server environment with existing dashboards, Agent alerts, and job status checks
Main concernMonitoring existed, but the team still learned about some issues too late
Service fitSQL Server health audit
Primary riskNoisy or incomplete signals could hide the events that actually needed action
Useful outputA shorter alert list with clearer owners, thresholds, and follow-up checks

Technical evidence reviewed

The audit looked at the alerts that fired, the alerts that never fired, backup and job visibility, baseline quality, wait and blocking evidence, and whether the team had enough context to separate normal noise from risk.

It also checked ownership. Some alerts had no clear recipient. Some were too noisy to respect. Some important checks were not being watched at all.

The review treated monitoring as an operating system, not a product list. A tool is only useful if someone trusts the signal and knows what to do next.

EvidenceWhat it checked
SQL Agent operators and alertsWhether critical SQL errors, failed jobs, and backup failures reached a current owner
Database Mail and notification historyWhether alert delivery itself was healthy
Backup, CHECKDB, and long-running job checksWhether routine operational failures were separated from dashboard noise
Waits, blocking, deadlocks, and file growth eventsWhether runtime pressure had useful visibility
Alert frequency and ownershipWhether people had been trained to ignore the system

Findings

The review found a signal-quality problem. The team had monitoring, but not enough confidence in what deserved attention first.

Some alerts were kept. Some were rewritten. Some were moved out of the urgent path because they had trained people to ignore the system.

FindingEvidenceRiskPractical action
Alert urgency was unclearSeveral checks fired without a clear severity or ownerPeople could ignore the signal until it became user-visibleDefine action levels and owners
Backup visibility was mixed with general noiseBackup status existed, but restore-risk signals were not separatedRecovery risk could hide behind routine dashboard healthSplit backup failure, backup age, and restore-proof checks
Job failures depended too much on manual reviewSome job states were easiest to find by opening historyA routine failure could become old before anyone actedRoute failed jobs to a named owner
Runtime baselines were thinWaits, blocking, file growth, and job duration had limited comparison contextThe team could not tell normal pressure from a bad trendCapture simple baselines for important periods

Fix order

The output did not recommend more dashboards first. It recommended making the existing signals easier to trust.

The order was practical: make critical failures visible, reduce noise, then add baseline evidence where the team actually needed it.

WhenWorkWhy first
First 48 hoursConfirm failed-job, backup-failure, and high-severity SQL alert deliveryThese are basic operating signals
First weekAssign current owners and remove dead recipientsAn alert without an owner is only decoration
First weekSeparate urgent alerts from review-only signalsNoise makes real problems easier to miss
Next 2 weeksAdd simple baselines for waits, blocking, file growth, and job durationTrends make future incidents easier to judge
Later cleanupImprove dashboards after the alert model is sanePresentation should follow signal quality

Outcome

Monitoring gaps often hide behind the fact that monitoring exists. That makes the buying moment awkward because the environment can look covered while still being weak under pressure.

This case shows why a health audit should look at alert usefulness, not only alert presence. If the signals do not help the team decide, they are decoration with a monthly cost.

When this applies

This case applies when monitoring tools exist, but production issues still arrive through users, delayed symptoms, or manual checking.

It is a health-audit problem when the team needs to know which signals are worth trusting before the next incident.

  • Monitoring exists but confidence is low
  • Alerts are noisy or poorly owned
  • Failed jobs and backup issues are too easy to miss
  • The team cannot separate urgent signals from review-only noise
  • Future performance or recovery work needs better baseline evidence