Database Management

SQL Sentry 2.0 Alert Trap overrides SQL Server Agent alert responses in SQL Sentry

This article explains why the SQL Sentry 2.0 Alert Trap job appears to take over existing SQL Server Agent alerts and how to prevent SQL Sentry from managing specific SQL Agent alerts when you want to use your own custom response jobs instead.

First published date

1/16/2026 11:36 PM

Last published date

1/16/2026 11:36 PM

Overview

After installing or upgrading to SQL Sentry 2025.2, some environments observe that existing SQL Server Agent alerts that previously executed a custom response job now appear to be routed through the SQL Sentry 2.0 Alert Trap (SQL Sentry Jobs) job instead. This happens even when the customer did not create those alerts or jobs through SQL Sentry and does not want SQL Sentry to manage paging or notifications for that alert sequence.

When the underlying condition fires:

  • The SQL Agent alert’s configured response is changed (or appears to be changed) to execute the SQL Sentry 2.0 Alert Trap job.
  • Notifications and paging configured in SQL Sentry may fire in addition to, or instead of, the actions defined in the customer’s original custom response job.
  • Disabling related alerting conditions in the SQL Sentry client does not stop the SQL Sentry 2.0 Alert Trap job from being invoked, because the SQL Agent alerts are still configured to execute that job at the SQL Server level.

Product section

SQL Sentry (SQLS)

Cause

This behavior is by design in the current implementation of the SQL Sentry 2.0 Alert Trap:

  • During installation, SQL Sentry creates a SQL Server Agent job on each monitored instance named SQL Sentry 2.0 Alert Trap (SQL Sentry Jobs).
  • This job is tied to the Agent Alert Fired general condition in SQL Sentry. Its purpose is to funnel SQL Server Agent alerts through SQL Sentry’s alerting channels, enabling SQL Sentry to centrally manage notifications.
  • As part of that wiring, the install process changes the default Response for SQL Server Agent alerts so that, when an alert fires, it executes the SQL Sentry 2.0 Alert Trap job if no explicit alternative job is configured.
  • Because of this default behavior, even if the SQL Sentry 2.0 Alert Trap condition is disabled in the SQL Sentry client, SQL Agent alerts may still appear to originate from (or be associated with) the SQL Sentry 2.0 Alert Trap job as long as those alerts remain linked to that job at the SQL Server level.

Resolution

Workaround: Remove specific SQL Agent alerts from SQL Sentry 2.0 Alert Trap

Use this procedure on the affected target when you want certain SQL Server Agent alerts to remain completely independent of SQL Sentry’s alert trap behavior, while still allowing other alerts to use SQL Sentry 2.0 Alert Trap.

  1. In SQL Server Management Studio (SSMS), locate the SQL Sentry 2.0 Alert Trap job, then open its properties.
  2. Navigate to the Alerts section in the SQL Sentry 2.0 Alert Trap job properties. (It should list all the Alerts associated with the SQL Sentry 2.0 Alert Trap.)
  3. Review the list of SQL Server Agent alerts linked to the Alert Trap.
  4. Remove unwanted alerts from the Alert Trap alert list. (This breaks the mapping that causes the SQL Agent alert to execute the SQL Sentry 2.0 Alert Trap (SQL Sentry Jobs) job by default, allowing your own response job configuration to take precedence once you set it in the individual Alert.)
  5. Verify the SQL Server Agent alert configuration in SSMS.
    1. Open each alert you modified via the SQL Sentry Alert Trap properties.
    2. Confirm that the Response section now reflects the behavior you want (for example, executing your custom job) and is not wired to the SQL Sentry 2.0 Alert Trap job unless you intend it to be.