ALERT

Config path: /<database>/<schema>/alert/<name>.yaml

Example:

warehouse: al001_wh1
schedule: 1 minute

condition: |-
  SELECT gauge_value
  FROM ${{ env_prefix }}db1.sc1.gauge
  WHERE gauge_value>200

action: |-
  INSERT INTO ${{ env_prefix }}db1.sc1.gauge_value_exceeded_history
  VALUES (current_timestamp())

Schema

• warehouse (ident) - warehouse used to executed alert

• schedule (str) - schedule for periodically evaluating the condition for the alert

• condition (str) - SQL statement that represents the condition for the alert

• action (str) - SQL statement that should be executed if the condition returns one or more rows

• comment (str)

Usage notes

1. SnowDDL only creates alerts. Alerts are initially suspended. You should execute ALTER ALERT ... RESUME via different means to enable alert execution.

2. Schema objects should be referred using fully-qualified identifiers, with ${{ env_prefix }} placeholder, database name, schema name and object name. It is currently required due to limitations of ALTER ALERT command missing scope during validation of SQL statements.

3. Alerts can only be created via SnowDDL config. Users with OWNER privilege on specific schemas cannot create custom alerts in such schemas.

4. Alerts are executed with full privileges of SnowDDL Administrator User role.

Additional privileges

In order for ALERT objects to operate properly, the following additional grants should be added to OWNER role in schema config:

• owner_warehouse_usage - list warehouses used to execute alerts

• owner_integration_usage - if you send alert notifications, add name of notification integration here

• owner_account_grants - Snowflake requires EXECUTE ALERT or EXECUTE MANAGED ALERT privilege to run alerts

Links

• CREATE ALERT
• ALTER ALERT
• SHOW ALERTS
• Setting up Alerts
• Parser & JSON Schema (GitHub)