Database alerting best practices start with a simple fact: data is the most important asset in IT. Early in my career, a big crash took down a costly server. The CIO didn’t ask about the hardware. Instead, he asked, “What happened to my data?” That’s why alerting matters so much for DBAs.

Most of us get too many alerts, and most need no action. Yet each alert still takes time and attention. As a result, alert fatigue sets in. When you’re surrounded by noise, you start to overlook the signals that matter, and mistakes follow. (The 2025 State of Database Report lists alert fatigue among the strains on DBA teams.)

My examples use SQL Server, but the principles apply to any platform.

Database alerting best practices start with a good alert

Alerting isn’t monitoring. Monitoring collects telemetry, while an alert demands a response. In my mind, alert equals action. Database alerting best practices set a simple bar: each alert should be:

  • Informative. It tells you what you need to know to take the next step.
  • Actionable. You, or a script, can do something about it.
  • Traceable. You can retrace what triggered it.
  • Prioritized. You know what needs a response now, within an hour, or in the morning.
  • Deterministic. The same situation always raises the same alert.

If an alert doesn’t meet this bar, it’s noise. For example, SQL Server used to tell me when a backup succeeded. But I only need to know when a backup fails, runs too long, or never finishes.

Turn noise into signal

Some noise deserves attention. It only matters in aggregate.

One or two failed logins are a mistyped password. But thousands in a short window can point to an intrusion attempt. Likewise, a handful of SQL syntax errors is normal, but a sudden surge can indicate a SQL injection attack.

So don’t page yourself for each event. Instead, log the low-priority ones and track them over time. Then alert when the count moves beyond normal. That’s when noise becomes a signal.

Six database alerting best practices to reduce alert fatigue

Database alerting best practices shift you from firefighting to fireproofing.

  1. Use maintenance windows. If you patch on the first Tuesday of the month, suppress alerts for that window, then switch them back on.

  2. Throttle responses. A CPU spike that drops straight back to normal isn’t worth a page. Alert only when a condition lasts, say, three to ten minutes. This also prevents alert storms. A replication failure can send thousands of messages in minutes.

  3. Skip notifications that need no action. Aggregate informational alerts instead.

  4. Send digests for job failures. Collect SQL Server Agent job failures in one place and review them as a queue.

  5. Watch specific error numbers. Many serious errors aren’t high severity. Error 825, for example, is an early warning of storage problems. I turn on severity alerts from 18 and up, then add error numbers. Microsoft documents severity-based alerts in SQL Server Agent.

  6. Audit your alerts. My teams reviewed theirs about every six months. They retired alerts that no longer fired, reprioritized others, and added new ones.

Make sure someone responds

An alert only helps if it reaches the right person with enough information to act.

  • Use distribution lists, not individual addresses. Your coverage shouldn’t depend on one person’s holiday.
  • Configure a fail-safe operator. If the server is too busy to send mail, you still hear about it.
  • Build escalation paths. If nobody acknowledges a critical alert in time, escalate to the admin team, then to management.
  • Put the essentials in the subject line. Include the server name, severity, error number, and a snippet of the message. At 3 a.m., that tells you whether you’re getting out of bed.
  • Automate the first response. An alert can run a job that captures sp_WhoIsActive output. One DBA I know keeps an empty 5 GB file on the log drive. When the drive fills, an alert deletes it and buys time to fix the cause.

For many servers, script your alerts instead of using the GUI. Azure SQL has no SQL Server Agent. Use an Extended Events session there to capture severity 16 and above, plus key lower-severity errors.

Use baselines, not fixed thresholds

A fixed threshold, such as CPU above 90%, is useful but incomplete. If your server normally runs at 30% to 35% CPU, a sudden drop to 10% matters too. In my environment, that meant a router had failed and a whole division couldn’t reach the server. A 90% threshold would never have told me.

If you don’t know what normal is, you can’t recognize abnormal. So build a baseline and alert on deviation, such as one or two standard deviations from normal. If your workload changes at month end, build a separate baseline for that period. Baselines also support the evidence-based approach I describe in More Databases, Same Headcount?

How SolarWinds tools support database alerting best practices

You can build all of this natively, but it takes work. SolarWinds database monitoring tools include much of it:

  • SolarWinds® Database Performance Analyzer (DPA) software supports custom alerts built on a SQL statement, with priority levels and escalation paths. It covers more than 30 relational platforms from one interface.

  • SolarWinds SQL Sentry® software uses advisory conditions, which can be custom queries or full stored procedures. It includes built-in baselines for the previous 30 minutes, day, or week. You can also create custom baselines from the performance graph. Query Store conditions aren’t built in, so download them from the THWACK community or GitHub.

  • Platform Connect, available with licensed DPA or SQL Sentry, can route alerts to ServiceNow, PagerDuty, and other ticketing systems.

Frequently asked questions

What’s the difference between monitoring and alerting?

Monitoring collects telemetry about how your databases behave. Alerting calls for a response. You need both.

What are the most important database alerting best practices?

Alert only on conditions that need action. Then use maintenance windows, throttling, digests, baselines, and regular audits to keep the signal clear.

Why use standard deviation instead of a fixed threshold?

A baseline shows what’s normal for your workload. Deviation from it catches unusual lows as well as highs.

Do database alerting best practices work outside SQL Server?

Yes. Commercial platforms have comparable alerting. Open source platforms such as PostgreSQL and MySQL typically need a plug-in or custom code.

Which SolarWinds tool should I use?

DPA covers many relational platforms. SQL Sentry goes deepest on the Microsoft data platform. SolarWinds Database Observability software is SaaS-first and covers non-relational platforms such as MongoDB and Redis.

Resources

Tags:
database monitoring