Databricks SQL Alerts work. They also need a warehouse running.

Two different starting points

If a SQL warehouse is already running for your team's dashboards, native Alerts cost you almost nothing extra to add. If you're an individual engineer with a personal connection to a shared Databricks workspace and no dashboard infrastructure of your own, the calculation is different, you'd be setting up alert objects and thinking about warehouse availability for a check that's really just for you.

What Databricks SQL Alerts actually offer

Databricks' own Alerts documentation describes a solid, native feature: a saved query, a schedule, a condition, and a notification destination that includes Slack. This isn't a workaround, it's a first-class part of Databricks SQL, and if your team already has a warehouse provisioned and running for reporting, adding an alert on top of it is close to free.

The part that's easy to underestimate

The alert's condition query has to actually execute against something, and that something is a SQL warehouse. If the warehouse auto-stops when idle, which is the sensible default for cost control, each scheduled alert check can trigger a cold start, adding latency and a small compute charge every time. Keeping a warehouse running continuously to avoid that removes the cold start but adds a standing cost of its own. Neither is wrong, it's just a real trade-off that a lightweight, occasional check doesn't always want to take on.

The same check from QueryFlow

Say you want to know if a Unity Catalog table stopped getting new rows overnight:

SELECT COUNT(*) AS new_rows
FROM main.analytics.events
WHERE event_date = current_date() - 1;

Run that in QueryFlow against your Databricks connection, click Watch this, choose A value on new_rows, condition Equals 0 (or Less than a floor), check every 1d, and destination Slack. The check runs on whatever schedule you pick, using the warehouse connection you already have, and the cost and cold-start question is the same one you'd already be managing for that warehouse day to day, it doesn't add a second alerting system's worth of scheduling on top.

Where native Alerts are clearly the right call

For a data-quality check the platform team owns, that needs to live inside Databricks' own governance and run regardless of whether any particular person's laptop is on, native Alerts are the correct tool, full stop. This page isn't arguing against that. It's aimed at a narrower, common situation: an individual engineer or analyst who wants one query watched and doesn't want to become the owner of a new alert object inside a shared warehouse for it.

Side by side

Setting up your first Watch

Run or open a query in the SQL Editor, 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, run a preview, and save. Full walkthrough: the Watch This tutorial.

A note on the 25 MB result limit

Databricks results over 25 MB need a LIMIT or fewer columns, worth knowing before you build a Watch around a query that scans a wide, high-cardinality table without narrowing it down. A row-count or single-value check, the shape most Watches take, almost never runs into this since the result being checked is a handful of numbers, not raw rows. If you're watching something closer to Any change on a broader result set, keep the query itself scoped, a WHERE clause on a recent date range, or a LIMIT on the rows returned, the same discipline you'd already want for any interactive query against a large Unity Catalog table.

Checking across catalogs

A single Databricks connection can browse and query across catalogs if you leave the connection's Catalog field blank, letting you pick a different one per query rather than being locked to a single catalog per connection. That matters if the table you want watched sits in a different catalog than the one you use day to day, no second connection required, just qualify the query with the right catalog.schema.table path.