DAM Alerting

DAM Alerting matches Database Activity Monitoring audit events — including the query and connection activity DAM captures — against user-defined alert rules and sends notifications to email and integration channels when a rule fires. It works across both Snowflake and OLTP audit data. An alert rule is a filter expression plus a delivery configuration: when audit activity matches the filter, the rule fires and ALTR notifies the configured recipients and channels.

Note

DAM Alerting is a notification-only alert-rule engine over Database Activity Monitoring audit data, covering both Snowflake and OLTP, configured in its own rule wizard. It’s distinct from Policy Alerts, a legacy, Snowflake-only feature configured inside a masking policy that can block access. Both surface in the same Triggered Alerts view in ALTRNet.

Rule Types

An alert rule is one of two types, fixed at creation:

• Match rule — fires once per matching audit event, with no per-match cooldown.
• Threshold rule — counts matching events over a time window (hourly, daily, weekly, or monthly) and fires when the count reaches the threshold.

Threshold windows are anchored to the wall clock in the rule’s configured time zone (default UTC), not to when the rule was created — an hourly window starts at the top of the hour, a daily window at local midnight, a weekly window on Monday at 00:00, and a monthly window on the first of the month. The count resets at each window rollover. When the count crosses the threshold mid-window, the rule fires immediately rather than waiting for the window to close, and fires only once per window — further matches in the same window don’t produce additional triggered alerts until the next window begins.

Alert Rule Filters

Each rule’s filter is a logical tree of AND/OR branch nodes combining typed leaf predicates, for example, “statement type is SELECT” AND “row count greater than 100000.” In the rule wizard, a condition group’s any / all toggle selects OR (any) or AND (all); the tree supports up to 16 levels of nesting and up to 256 nodes total.

A rule targets a Connection Type: a Snowflake connection or an OLTP connection. The available filter fields depend on it.

Common fields (available for both Snowflake and OLTP): user, database, schema, table, column, statement type, statement text, event name, time of day, and row count.

Snowflake-only fields: role, roles, warehouse, warehouse size, IP address, Snowflake client, session, query tag, account, account region, masking policy, column policy, execution duration, and tag name and tag value.

OLTP-only fields: query status (success, failure, or blocked), repository user, client IP, client application, client port, repository type, repository host, sidecar, connection authorized, authorization type, bytes returned, policy applied, policy type, user email, and user group.

Operators vary by field type: string fields support equals, not equals, in, contains, and regex; IP-address fields (IP address, client IP) additionally support CIDR; numeric fields support greater/less than (and their inclusive variants) and range; query tag supports key-exists and key-equals; time of day supports between; and any field supports exists.

Severity and Acknowledgment

Every rule carries a severity of low, medium, high, or critical, used for triage. A rule can require an acknowledgment comment, in which case a responder must enter a comment when acknowledging a triggered alert it produces.

Delivery Channels

DAM Alerting delivers to email plus six integration channels, enabled per rule as toggles in the rule wizard:

Channel	What it does
Email	Sends a notification to each recipient’s email address, with per-rule one-click unsubscribe and rate limiting
Webhook	POSTs a JSON payload to your endpoint
Slack	Posts alerts to a Slack channel via the ALTR app
Splunk	Forwards alerts to a Splunk HTTP Event Collector
PagerDuty	Triggers an incident in a PagerDuty service
ServiceNow	Opens a record in a ServiceNow table, defaulting to incident
Microsoft Teams	Posts alerts to a Teams channel via a Power Automate workflow

A rule can specify up to 100 email recipients. Email delivery is rate-limited per rule: the minimum interval between emails for a given rule defaults to 300 seconds and can be set between 60 seconds and 24 hours. The rate limit gates email only — integration channels such as webhooks are never rate-limited.

Each alert rule delivers to whichever channels are enabled on that rule; there’s no separate cross-rule routing layer. Set up and manage channel connections — provider setup, credentials, and connection health — from Settings > Integrations; see Notification Integrations for configuration and management detail.

After repeated delivery failures attributable to customer configuration, ALTR suppresses the affected integration until it’s corrected, and a rule’s notifications to that channel stop until then. Notification Integrations covers how channel health and delivery failures are managed.

Notification Volume

When more than one triggered alert for the same rule occurs within the rate-limit window, only the first sends an email — the rest are dropped from email, not queued or merged into a later email — but all remain visible in Triggered Alerts and are still delivered to any enabled integration channels. Separately, when several distinct triggered alerts for the same recipients are processed together, they’re combined into a single email that shows up to 5 alerts and summarizes the rest as “…and N more,” linking to the Triggered Alerts view.

Rule Versioning and Immutability

Rule type, filter, connection type, and (for threshold rules) window type, threshold, and time zone are immutable after creation — changing any of them requires deleting and recreating the rule. Name, description, enabled state, severity, recipients, the email rate-limit interval, and the acknowledgment-comment requirement can be edited. Each create or update produces a new rule version.

Rule creates, updates, and deletes are recorded in the System Audit Log’s Alerts category, which covers DAM Alerting rule changes.

Create an Alert Rule

To create an alert rule:

1. Select Alerts > Alert Rules in the navigation menu.
2. Click Create Alert Rule.
3. Enter a name and, optionally, a description.
4. Select a Connection Type — a Snowflake connection or an OLTP connection.
5. Under Define Conditions, build the rule’s filter: set a condition group’s any / all toggle, then click Add Condition for a field, operator, and value, or Add Sub-condition / Add Rule to nest further groups.
6. For a threshold rule, set the time window, threshold count, and time zone.
7. Select a Severity and, optionally, require an acknowledgment comment.
8. Toggle the delivery channels to enable (Email, Webhook, Slack, Splunk, PagerDuty, ServiceNow, Microsoft Teams) and enter each channel’s connection details.
9. Click Create Rule. ALTR displays “Audit alert rule created”.

Triggered Alerts

Once enabled, a rule evaluates incoming audit activity continuously; when it fires, ALTR dispatches notifications to the enabled channels and the triggered alert appears under Alerts > Triggered Alerts. A triggered alert has two states: new and acknowledged.

To acknowledge a triggered alert:

1. Select Alerts > Triggered Alerts in the navigation menu.
2. Click the triggered alert to open its detail view.
3. If the rule requires an acknowledgment comment, enter one.
4. Click Acknowledge. The alert’s state changes to acknowledged; this is one-way — there’s no separate resolved state, and an acknowledged alert can’t be reopened.

Responders can also add free-form comments to an alert independently; comments are append-only.

Policy Alerts events that surface in the same Triggered Alerts view display a Resolve Alert button instead of Acknowledge; the underlying states are the same, and the difference is a UI label only.

Data Source Behavior

On Snowflake, DAM Alerting rules evaluate the audit records captured through the Snowflake Cloud Integration, which captures only SELECT queries on connected columns — DDL, DML beyond SELECT, DCL, and queries on non-connected columns produce no audit records and can’t match a rule. See Snowflake Integration Overview for what Snowflake capture includes.

On OLTP, DAM Alerting rules evaluate audit records captured by the sidecar and by Security Intelligence Scout, which can run alongside or instead of each other; sidecar-captured records include all statement types and connection events. See Sidecar Integration Overview for what OLTP capture includes. Match-rule alert details for OLTP events show the database, schema, table, and statement text associated with the matched audit event, consistent with Snowflake match-rule alert details.

API Surface

Alert rules are managed through the DAM Alerting API, and integration channels through the Notification Integration API — both listed in ALTR’s API catalog.