Two ways to get a Snowflake result into Slack.

Who each is for

Snowflake's native alerting fits a team that wants everything, including the alert logic itself, to live inside the warehouse under normal Snowflake governance: version-controlled in a migration, owned by a role, auditable the same way a table is. QueryFlow's Watch This fits someone who wants a specific number checked and a message sent, without writing or maintaining a database object to do it.

Snowflake's native ALERT, start to finish

Snowflake's own CREATE ALERT documentation lays out the shape: you write a condition query, a schedule, and an action. A simplified version, checking for failed orders:

CREATE OR REPLACE ALERT failed_orders_alert
  WAREHOUSE = reporting_wh
  SCHEDULE = '60 MINUTE'
  IF (EXISTS (
    SELECT 1 FROM sales.public.orders
    WHERE status = 'failed'
      AND created_at >= DATEADD(hour, -1, CURRENT_TIMESTAMP())
  ))
  THEN CALL SYSTEM$SEND_SNS_MESSAGE(
    'my_notification_integration',
    'sns-topic-arn',
    'Failed orders detected in the last hour.'
  );

ALTER ALERT failed_orders_alert RESUME;

Getting that action clause to actually land in a Slack channel takes a separate piece: a notification integration pointed at a webhook, an SNS topic wired to a Lambda that posts to Slack, or an equivalent. Snowflake's own docs walk through configuring a notification integration, and it's a one-time setup per destination, but it is infrastructure you own, with its own permissions and failure modes to debug when a message doesn't show up.

The same check as a Watch

Run the equivalent query in QueryFlow's SQL editor against your Snowflake connection:

SELECT COUNT(*) AS failed_orders
FROM sales.public.orders
WHERE status = 'failed'
  AND created_at >= DATEADD(hour, -1, CURRENT_TIMESTAMP());

Click Watch this, choose A value on failed_orders, condition Greater than with a threshold of 0, check every 1h, and tick Slack under Destinations. No CREATE ALERT, no notification integration, no ACCOUNTADMIN grant to set up. The trade is that this alert now depends on QueryFlow rather than living entirely inside the warehouse.

Side by side

When to pick each

Pick native CREATE ALERT when the alert logic needs to be owned by the data platform team, versioned in the same migrations as your tables, and independent of any client software being installed anywhere. Pick a Watch when a person or a small team wants a specific check running without asking a platform team to stand up a notification integration first. Plenty of teams end up using both: native alerts for platform-owned data-quality checks, Watches for the smaller, personal "tell me if this number moves" checks nobody wants to file a ticket for.

Setting up your first Watch

Run your query, click Watch this, name it, and confirm the connection and SQL. Choose Row count, A value, or Any change, pick a condition, set Check every, tick Destinations, then Run preview and Save. Full steps with screenshots: the Watch This tutorial.

What happens when the query itself fails

A native Snowflake alert that references a table that's been dropped, or a role that's lost a grant, fails silently unless you're specifically monitoring the alert's own run history, which is a second thing to remember to check. A QueryFlow Watch surfaces a failed check directly, right-click a Watch and Check now shows you whether the underlying query itself ran cleanly, separate from whether its condition fired. That distinction matters more than it sounds: a Watch that's gone quiet because nothing changed looks identical from the outside to a Watch that's gone quiet because the query started erroring, until you actually check.

Combining both approaches on the same table

Nothing stops a team from running native `CREATE ALERT` objects for platform-owned checks on a shared table, while individual engineers add their own Watches on the same table for personal, narrower questions, "let me know if my specific customer segment's order count drops," without asking the platform team to add a new alert object for a one-off curiosity. The two systems don't conflict, they're reading the same data through two different paths, one governed centrally, one set up in a couple of clicks by whoever needs it.