Why This Feature Exists — and Why You Should Be Using It You’ve already got SQL DM watching your servers and firing alerts when thresholds...
You’ve already got SQL DM watching your servers and firing alerts when thresholds break. But what happens after the alert fires? If the answer is “someone checks their email… eventually,” then you’re leaving a lot of value on the table.
Alert Actions and Automated Responses is the part of SQL DM that turns a passive alert into an active response. Instead of SQL DM shouting into the void, it can email a distribution list, kick off a SQL Agent Job to remediate the problem, run a PowerShell script, open a ServiceNow ticket, fire a T-SQL cleanup script, capture detailed query data, or any combination of these — all without a human in the loop.
The result: faster mean time to response (MTTR), fewer “I didn’t see the alert” post-mortems, and a monitoring setup that actually does something when problems surface.
Use this feature when:
Poorly scoped alert rules create the same noise as poorly set thresholds — get these decisions right upfront.
You need Modify access on the SQL DM console to create or edit alert response rules. View-only users can open the Alert Actions and Responses window but cannot change anything. The SQLdm Management Service account also needs appropriate permissions on any target servers for SQL Agent Job and SQL Script actions — verify this before you assume a rule will fire correctly.
By default, a new alert response rule fires for every instance, every metric, every severity level, at any time. That default is almost always wrong. Use conditions from the start to scope your rules — otherwise your on-call team gets emailed every time a dev server hits 50% CPU.
Every action provider has a Test button. Use it. For PowerShell, SQL Script, and SQL Agent Job providers, test output goes to the console — verify it does exactly what you expect before the action fires in response to a real event. For SMTP, send a test email and confirm it arrives and renders correctly.
When you add a new rule, every action provider inside it is disabled until you explicitly enable it. You won’t get unexpected emails or runaway scripts from saving a draft rule — but you also won’t get anything until you toggle it on.
If you need the same rule with one or two settings changed (different recipients, different instance scope), use the Copy function from the Alert Responses tab and edit the copy. Much faster than rebuilding from scratch.
Alert response rules can be exported to XML and imported into other SQL DM instances. If you’re maintaining multiple environments (dev, staging, prod) or SQL DM repositories, export your production rules and import them rather than rebuilding manually.
ServiceNow integration requires the connecting account to have the evt_mgmt_operator and soap roles for basic authentication. Missing either role causes silent failures — verify in ServiceNow before wiring up the action provider.
The Program Action Provider runs executables only. If you need to run a batch file, wrap it: cmd /c run.bat. The PowerShell provider is more flexible and preferred for most scripting needs.
This guide covers the two-phase setup: configuring your Action Providers (the communication channels), then creating your Alert Response Rules (the logic that decides when to use them).
Action Providers are the communication channels SQL DM can use — SMTP servers, SNMP traps, ServiceNow instances. Configure these first so they’re available to reference when you build your rules.
From the SQL DM Console menu, click the wrench icon (⚙) and select Alert Actions and Responses.
The Alert Actions and Responses window has two tabs: Alert Responses and Action Providers. Click the Action Providers tab.
Action Providers tab showing the list of configured providers.
Click Add to open the Alert Communications Wizard. Select SMTP and complete the wizard:
📝 If your SMTP server requires TLS or uses a non-standard port, confirm those settings with your network team before testing. Authentication failures in SQL DM won’t generate detailed error messages in the UI.
Click Add and select SNMP. Enter the NMS host, port (default 162), and community string. Test before saving.
Alert Response Rules are where the logic lives: when this happens → do this. Each rule combines conditions (scope and triggers) with one or more action providers (what to do).
In the Alert Actions and Responses window, click the Alert Responses tab. SQL DM includes two rules enabled by default — review them before adding your own. Click Add to create a new rule.
Alert Responses tab showing the list of rules with Enabled/Disabled status
Give the rule a descriptive name that conveys what it does and when — e.g., “Production CPU Critical — Email DBA Team” or “Blocking >5min — Run Kill Script”. Vague names like “Rule 1” make auditing painful.
In Step 3 of the Alert Response window, you’ll see the rule description with clickable hyperlinks for each condition. Click the underlined values to define them. Without conditions, the rule fires for every metric on every instance.
The available conditions and their best use cases:
| Condition | Use It When… |
| SQL Server Instance is in specified list | You want the rule to fire only for certain instances (e.g., production servers only) |
| SQL Server Instance has tag in specified list | You tag instances by environment or team — fire for “Tier 1” only, for example |
| Metric is in specified list | Scope the rule to one alert metric (e.g., CPU only) |
| All metrics are in specified list | Require multiple metrics to breach simultaneously before firing |
| Metric severity has changed | Avoid repeat notifications; fire only on severity transitions (OK → Warning, etc.) |
| Refresh occurred during time frame | Business-hours-only notifications; suppress overnight noise |
| Alert Rank value | Fire only for high-impact alerts (rank > X) — useful when triaging by business priority |
| Metric severity unchanged for N minutes | Escalate a persistent problem: “if Critical for more than 15 minutes, page the DBA” |
📝 “Where metric severity is unchanged for a specific time period” is evaluated once when the duration is met — the timer does not repeat. It re-evaluates only after the severity changes and then remains unchanged again for the full period.
In the rule editor, scroll through the list of available action providers. Each is disabled by default. Click Enable next to the ones you want to use for this rule, then configure each one.
📝 The PowerShell command runs under the SQLdm Management Service account. That account needs the relevant permissions — network access, API credentials, etc. — for the script to work.
Click OK to save. The rule is saved in a disabled state. Back on the Alert Responses tab, locate the rule and check the Enabled checkbox to activate it.
Alert Response window showing condition summary and action provider selection
The cleanest verification is to temporarily lower a threshold on a test instance, let an alert fire, and confirm the action triggered as expected — email received, job ran, ticket opened. After confirming, reset the threshold. For rules you can’t easily test against a real alert, the Test button on each action provider is your next best option.
📝 SQL DM’s Change Log records rule additions and modifications per-instance (same behavior as the baseline configuration apply function). Check the Change Log if you need an audit trail of when rules were created or last changed.
All Action Providers at a Glance
| Action Provider | What It Does | Best For |
| Email (SMTP) | Sends alert email via configured SMTP server | On-call notifications, team distribution lists |
| EventLog | Writes an entry to the Windows Event Log | SIEM ingestion, compliance audit trails |
| SNMP Trap | Sends SNMP trap to your NMS console | Environments with centralized network mgmt (SolarWinds, etc.) |
| PowerShell | Runs a PowerShell script on the SQLdm Management Service host | Automated remediation, ticketing API calls, custom logic |
| Program (.exe) | Launches an executable on the Management Service host | Legacy automation, custom notification tools |
| SQL Agent Job | Kicks off a SQL Agent Job on the affected (or any) instance | Automated maintenance, corrective T-SQL workflows |
| SQL Script | Executes T-SQL on a target instance | Kill runaway sessions, update config values, log to custom table |
| Query Monitor | Auto-enables Query Monitor to capture more detail | Diagnosing intermittent query problems when alert fires |
| Query Waits | Auto-enables Query Waits collection | Wait-stat triage triggered by a blocking or deadlock alert |
| Prescriptive Analyzer | Runs prescriptive analysis on the offending server | Deep-dive diagnostics without manual intervention |
| SCOM Alert/Event | Forwards alert or event to SCOM | Shops running System Center for unified alerting |
| ServiceNow | Creates an incident/event in ServiceNow | ITSM-integrated workflows and SLA tracking |
Additional Resources
Contact our sales team to get a personalized demo of our database management software for SQL Server!
