Snowflake has recently expanded alerting capability, allowing alerts to be sent via Email or Webhook. Webhook alerts are very powerful, because this enables the ability to send alerts to Slack, Microsoft Teams, Pager Duty, etc. This is useful for a variety of use cases including pipeline failure alerts and data driven alerts.

This post will provide a step-by-step guide to configure Snowflake alerts in Slack. We will cover a detailed example that will send an alert when warehouse usage increases.

Step 1: Create a Webhook in Slack

Log in to your Slack account, then go to this page.

Click Create an App

Choose “From Scratch”

On the next screen, give the app a name, choose a workspace, then click Create App

The next screen will present your Application Credentials.

Click Incoming Webhooks in the left sidebar:

Toggle “Active Incoming Webhooks” to “On”

After you change the toggle, scroll down to the bottom of that page and click “Add New Webhook to Workspace”.

Choose which channel you want the Snowflake alerts to go to. I created a new channel called “snowflake-alerts”, then I refreshed this page to get it to show in the dropdown.

Click Allow.

Test the Webhook

After you click allow above, the next page will give you your Webhook URL and a test CURL command.

Copy and paste the test command into your terminal. If you’re on Windows, use Git Bash.

It should instantly send a message to your new Slack channel.

Congrats, your new Webhook is now working!

Optional: Give the app a more attractive Snowflake ❄️ avatar

• Go back to the “Basic Information” tab.
• Scroll to the bottom.
• Download a Snowflake logo and upload it here.
• Test again.

Now it looks much better!

Step 2: Create Snowflake Secret

The Webhook URL contains a secret. Replace the secret string below with your secret string, then run this command in Snowflake.

Reminder: Secrets are schema level objects. Be careful about your worksheet database and schema context, or use fully qualified names.

In my case, I created a secret called gmds_slack_secret in the public schema of the analytics database.

1use schmea analytics.public;
2
3CREATE OR REPLACE SECRET gmds_slack_secret
4  TYPE = GENERIC_STRING
5  SECRET_STRING = 'T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX';

Step 3: Create a webhook notification integration

Now that we’ve successfully created the secret, let’s create the Notification Integration:

1CREATE OR REPLACE NOTIFICATION INTEGRATION gmds_slack_webhook_integration
2  TYPE=WEBHOOK
3  ENABLED=TRUE
4  WEBHOOK_URL='https://hooks.slack.com/services/SNOWFLAKE_WEBHOOK_SECRET'
5  WEBHOOK_SECRET=analytics.public.gmds_slack_secret
6  WEBHOOK_BODY_TEMPLATE='{"text": "SNOWFLAKE_WEBHOOK_MESSAGE"}'
7  WEBHOOK_HEADERS=('Content-Type'='application/json');

Step 4: Send the notification

To send a notification, we use the built-in SYSTEM$SEND_SNOWFLAKE_NOTIFICATION stored procedure. We must pass the SANITIZE_WEBHOOK_CONTENT function to the procedure to remove placeholder (i.e. SNOWFLAKE_WEBHOOK_SECRET from the message.

Here is the code I ran in my account:

1CREATE OR REPLACE NOTIFICATION INTEGRATION gmds_slack_webhook_integration
2  TYPE=WEBHOOK
3  ENABLED=TRUE
4  WEBHOOK_URL='https://hooks.slack.com/services/SNOWFLAKE_WEBHOOK_SECRET'
5  WEBHOOK_SECRET=analytics.public.gmds_slack_secret
6  WEBHOOK_BODY_TEMPLATE='{"text": "SNOWFLAKE_WEBHOOK_MESSAGE"}'
7  WEBHOOK_HEADERS=('Content-Type'='application/json');

The notification arrived in slack instantly!

Now that we have the basic gears in place, let’s move on to a real-world example.

Alerts Example: Send an alert when warehouse usage spikes

Craft a SQL query to identify warehouse usage spikes and wrap it in a serverless task

The following query compares recent usage (last completed hour), to the average hourly usage of each warehouse over the last month. In this case, we will flag warehouses with 50% increased usage.

We are using a serverless task because it will save us money! Just omit the warehouse name to make the task serverless.

For example purposes, I’m going to union a dummy record to ensure that every execution of the task produces a row and an alert.

1CREATE OR REPLACE TASK monitor_warehouse_spikes
2SCHEDULE = 'USING CRON 2 * * * * America/New_York'
3SERVERLESS_TASK_MIN_STATEMENT_SIZE = 'XSMALL'
4SERVERLESS_TASK_MAX_STATEMENT_SIZE = 'XSMALL'
5as
6insert into usage_spike_alerts (warehouse_name,last_hour_credits,avg_monthly_credits,credit_diff,percent_increase)
7WITH last_hour_usage AS (
8    SELECT
9        warehouse_name,
10        sum(credits_used) AS last_hour_credits
11    FROM
12        snowflake.account_usage.warehouse_metering_history
13    WHERE
14        start_time >= DATEADD(hour, -2, CURRENT_TIMESTAMP) 
15        AND end_time <= CURRENT_TIMESTAMP

Create a table to store the query results

1CREATE or replace TABLE usage_spike_alerts (
2    alert_id INT AUTOINCREMENT PRIMARY KEY,
3    warehouse_name STRING NOT NULL,
4    last_hour_credits FLOAT NOT NULL,
5    avg_monthly_credits FLOAT NOT NULL,
6    credit_diff FLOAT NOT NULL,
7    percent_increase FLOAT NOT NULL,
8    inserted_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
9    alert_sent boolean default false
10);

Note this table has a few helper columns with default values not included in the query results:

• alert_id: primary key
• inserted_at: helps us know when the task inserted the record.
• alert_sent: initially false, will be set to true after the alert is sent.

Test the task, review the results

1execute task monitor_warehouse_spikes;
2select * from usage_spike_alerts where not alert_sent;

Create a procedure to send the alert if a spike exists

We want to do the following:

• Check the usage_spike_alerts table for unsent records: alert_sent==false
• If we have unsent records, send them to slack.
• Mark the record as sent.
• Output the number of alerts sent in the SQL console.

1CREATE OR REPLACE PROCEDURE send_usage_spike_alerts()
2RETURNS STRING
3LANGUAGE PYTHON
4RUNTIME_VERSION = '3.8'
5PACKAGES = ('snowflake-snowpark-python')
6HANDLER = 'send_alerts'
7AS $$
8import snowflake.snowpark as snowpark
9
10def send_alerts(session):
11    query = """
12        SELECT warehouse_name, last_hour_credits, avg_monthly_credits, credit_diff, percent_increase
13        FROM usage_spike_alerts
14        WHERE alert_sent = FALSE
15    """

Manually test the procedure

We’ve already inserted a test row into the “spikes” table. Let’s run the sproc and ensure:

• The records are updated to alert_sent==true
• We receive the message in slack

1execute task monitor_warehouse_spikes;  -- if you haven't already...
2select * from usage_spike_alerts where not alert_sent; -- review it: sent == false
3CALL send_usage_spike_alerts(); -- send the alert
4-- wait for the alert to come
5select * from usage_spike_alerts where not alert_sent; -- 0 rows

You should have received an alert in Slack!

Chain the task and the procedure together

We want the hourly schedule of the monitor_warehouse_spikes task to handle the end-to-end process; let’s make sure that after the monitor_warehouse_spikes task is run, the procedure that sends the alert is also run.

First, wrap the procedure in a serverless task and turn it on:

1CREATE TASK send_usage_spike_alerts_task
2AS 
3CALL send_usage_spike_alerts();
4
5alter task send_usage_spike_alerts_task resume;

Next, chain the tasks together:

1ALTER TASK send_usage_spike_alerts_task 
2ADD AFTER monitor_warehouse_spikes;

Test it:

1execute task monitor_warehouse_spikes;

This task should now add the new records to the table and send the alert(s) to slack!

Review the task DAG and History

From the Data sidebar menu in the Snowsight UI (database icon in the sidebar), navigate to the database and schema that contains your tasks. Expand the tasks container and select either task we created. Then click the “Graph” tab in the main frame. Here you can manually trigger the task.

You can also review the task history on the “Run History” tab:

Design Notes

The query to check for spikes and sending the alert could have been done in a single task. One may argue that chaining two tasks adds unnecessary complexity. However, I like this design for the following reasons.

• The spikes are logged in a table forever. Technically this is not necessary for alerting, but it really nice to have.
  • Logging the spikes to a table is one unique unit of work and gets its own task.
• By abstracting the spike monitoring logic from the alert itself means we can change the logic without needing to re-test the send-alert functionality.

Wrap Up

Sending Snowflake alerts to slack is incredibly useful. The use cases for this type of alerting are endless!

This article has equipped you with the knowledge of:

• Creating a Webhook in Slack.
• Creating Secret in Snowflake.
• Creating a Webhook Integration in Snowflake.
• Creating a task to log warehouse usage spikes.
• Creating a procedure to send alerts based on a condition. In this case the existence of rows in a query.
• Wrapping a procedure in a task.
• Chaining tasks together.

I’m looking forward to hearing about the use cases you come up with! 🥂