Send a query's results to a webhook on a schedule.

Why a generic webhook, not just Slack or Teams

Slack and Teams destinations in QueryFlow are first-class: connect a workspace once and alerts render as formatted cards. A webhook is the escape hatch for everywhere else, an internal alerting service, a PagerDuty-compatible endpoint, a serverless function that fans a result out to three other systems, or a tool that doesn't have a QueryFlow-native integration yet. If Slack or Teams covers your case, use those; reach for webhook when the destination is something you built or something neither of those covers.

Before you start

You need a working connection, a query you want to check repeatedly, and a webhook URL that accepts an HTTP POST. Watch This is a Pipelines-tier feature; Studio doesn't include it.

A worked example

Say you want to know within 15 minutes if new orders stop coming in, a common early signal that a checkout flow or an upstream sync broke. On a Postgres connection:

SELECT count(*) AS recent_orders
FROM public.orders
WHERE created_at >= now() - interval '15 minutes';

Run it once in the SQL Editor to confirm it returns what you expect, then set up the watch.

Set it up

1. Run the query in the SQL Editor, or get it from an Ask answer.
2. Click Watch this on the results header.
3. Give it a Name (for example, "Orders stalled check"), and confirm the Connection and SQL are right.
4. Choose what to watch: A value, then pick the Column (recent_orders).
5. Choose a Condition: Equals, set to 0, since zero recent orders is the failure state.
6. Set Check every to 15m.
7. Under Destinations, tick Webhook and paste your endpoint URL.
8. Click Run preview to confirm it evaluates correctly against current data, then Save.

Check it worked

Use Send test message (or Check now from the Watches list, right-click menu) to fire the watch manually and confirm your endpoint receives a request. QueryFlow posts the check's result as JSON to the URL you provided; the exact fields your endpoint needs to parse are worth confirming with a test fire before you rely on it, the same way you'd test any webhook integration.

What it doesn't do

This is outbound only. QueryFlow doesn't expose an inbound webhook that triggers a sync or a query run on demand from an external event, everything runs on the interval you set, from 5 minutes to once a day. If you need "run this the instant an external system posts to me," that's a different pattern than Watch This provides, and you'd need something upstream of QueryFlow to poll or relay that event.

Webhook vs. the built-in destinations

Same watch logic, different landing spot. Pick based on where the alert actually needs to go and whether formatting matters.

Troubleshooting

Versus a cron job and a curl script

The DIY version of this is a small script: a cron entry that runs a query against your warehouse, checks the result in code, and calls curl against your webhook URL if a condition is met. It works, and plenty of teams run exactly that. What Watch This replaces is everything around the query itself: the background helper keeps checking on Snowflake, Redshift, BigQuery, and Databricks connections even with QueryFlow closed, the check history lives in the Watches list instead of a log file you have to go find, and changing the interval or condition is a form field instead of an edit-and-redeploy cycle. If you already have a script like this working and don't mind maintaining it, there's no urgent reason to switch. If you're about to write one, this replaces the maintenance burden with a UI.

Watching more than one signal at once

A single watch checks one query against one condition. For "alert me if any of these five tables goes quiet," you set up five watches, not one query with five conditions bundled in. That's more setup up front than a single clever query would be, but each watch fails independently and shows its own history, which makes it obvious which specific table stalled rather than one alert that could mean five different things. For a small number of signals, the handful most teams actually want paged on, the one-watch-per-signal model stays easy to reason about.

See the full Watch This tutorial for every option in the sheet, or why we built Watch This for the reasoning behind it.