A Snowflake Alert is a scheduled condition plus an action, built with SQL. Here's what it actually does, and what it leaves for you to wire up.
No credit card. 14 days. Cancel in one click.
Quick answer: A Snowflake Alert (CREATE ALERT) pairs a condition query with an action on a schedule, using warehouse compute, and starts SUSPENDED until you RESUME it. Reaching Slack or email means writing the action's SQL and a separate notification integration yourself. A Watch does the same job from outside Snowflake, no object to maintain.
A Snowflake Alert is a schema-level object, created with CREATE ALERT, that pairs a condition query with an action, run on a schedule you set with a cron expression or an interval. When the alert fires, it isn't a message on its own, it's closer to a scheduled procedure with a built-in truth check: if the condition query returns a result, the action runs, and the action is ordinarily a CALL to a stored procedure you've written. New alerts are created SUSPENDED and have to be explicitly RESUMEd, and Snowflake also suspends alerts automatically after certain account-level events, so an alert that "just stopped working" is often simply suspended again.
This makes an Alert fully native, no external tool needed, but it also puts the actual notification on you. Getting a message into Slack, Teams or email means configuring a Snowflake notification integration separately, then writing the stored procedure's SQL to call it, then keeping both current as your alerting needs change. An Alert object is powerful and entirely inside Snowflake, but it's infrastructure you build and own, not a feature you switch on.
A minimal Alert is a schedule, a condition query, and an action, written directly in SQL:
CREATE ALERT low_signup_alert
WAREHOUSE = analytics_wh
SCHEDULE = 'USING CRON 0 8 * * * UTC'
IF (EXISTS (
SELECT 1 FROM daily_signups WHERE signup_date = CURRENT_DATE() - 1 AND signup_count < 50
))
THEN CALL notify_low_signups();
ALTER ALERT low_signup_alert RESUME;
The IF clause is the condition query, the THEN clause is the action, and that last line is the RESUME every new alert needs before it does anything. notify_low_signups() is a stored procedure you write yourself, and it's the procedure's own SQL, not the alert object, that would call a Slack or email notification integration if you want the alert to actually reach anyone.
Keeping alerting entirely inside Snowflake means one less system with access to your data, and no external service to configure, review, or trust with credentials. For a team already comfortable writing and maintaining stored procedures, that trade is often worth the extra SQL. It's a real cost worth naming rather than a flaw: an Alert object is Snowflake-native and auditable, at the price of building and owning the notification path yourself.
QueryFlow's Watch This does the same underlying job as a Snowflake Alert, re-run a query, check a condition, notify somewhere, but from outside Snowflake and without an ALERT object, a stored procedure, or a notification integration to configure. Point a Watch at a saved query, pick a Condition (Changed, Greater than, Less than, and more) and a Destination, Slack or Teams among them, and save. There's no SQL object to create or maintain on the Snowflake side at all.
See row count alerts and threshold alerts for the QueryFlow side of this, and the Watch This tutorial for the full walkthrough.
A Snowflake Alert and a Snowflake Task are easy to conflate. A Task just runs SQL on a schedule, unconditionally, every time. An Alert only runs its action when the condition query actually returns a result. If what you want is "always run this," a Task is the simpler object; an Alert exists specifically for the "only run this when" case, which is the same distinction QueryFlow draws between a scheduled job and a Watch.
Not on its own. The alert's action runs SQL, typically a call to a stored procedure, and that procedure has to call a notification integration you've configured separately if you want it to reach Slack, Teams or email.
No. A new Alert is created SUSPENDED and has to be explicitly RESUMEd before it runs on its schedule.
Yes. Both the condition query and the action consume warehouse compute, the same as any other Snowflake query.
They solve the same problem, notice a condition and act on it, but an Alert is a native Snowflake object you write and maintain in SQL. A Watch is configured from a QueryFlow sheet, with no object, procedure or notification integration to build.
14-day free trial, no card. Point a Watch at a query instead.
No credit card. 14 days. Cancel in one click.