What counts as a row count change?

The number of rows your saved query returns, compared to the last check. Any difference at all trips Changed; a specific amount trips Increased by or Decreased by.

Can I alert on zero new rows, not just a spike?

Yes, that's exactly what Changed with Row count catches, a job that's gone quiet shows the same way a job with too many rows does, since both are a change from what the count normally does.

Does the query need a COUNT(*) in it?

No, Row count uses however many rows your query actually returns, whether that's a raw SELECT or an aggregated one. A COUNT(*) query returning one row isn't the same as Row count tracking that row's value, use A value for that instead.

What check interval makes sense for this?

Depends on how fast the table normally changes. An hourly ingestion table might want 1h; something that should only get new rows once a day fits better on a longer interval.

Which tier includes this?

Watch This, including Row count watches, is part of QueryFlow Pipelines.

Alert When a Table's Row Count Changes

Before you start

A query whose row count is meaningful to track, and QueryFlow Pipelines. Row count watches work on any connection.

Step by step

Run the query you want to keep an eye on, then click Watch this.
Name it, and confirm the Connection and SQL.
Choose Row count as what to watch.
Pick a Condition: Changed, Increased by, or Decreased by.
Set Check every, then choose Destinations and Save.

A worked example: catching a job that stopped

An hourly ingestion job is supposed to add new rows to a BigQuery table every run. Watch:

SELECT COUNT(*) AS row_total
FROM `my-gcp-project.raw.events`
WHERE DATE(_PARTITIONTIME) = CURRENT_DATE();

with Row count set to Changed and Check every 1h. A silent failure, the job stops running but throws no error, shows up as the row count staying flat between checks, exactly as visibly as a spike would. That's the case a fixed "alert if too high" threshold alone would miss.

A second worked example: catching duplication

On a Databricks table that should get exactly one row per order, watch with Increased by set higher than a single normal batch. If a retry logic bug inserts the same batch twice, the row count jump crosses that threshold and you hear about the duplication before it reaches a downstream report.

Check it worked

Run preview before saving to see the current row count. After saving, use Check now from the Watches list to confirm a check actually runs and, if you're testing a destination, that the alert arrives.

Troubleshooting

If you see	Fix
No alert despite an obvious count change	Check the Condition, Increased by won't catch a decrease, and confirm the Check every interval has actually elapsed.
Frequent false alerts	The table's row count may naturally fluctuate more than expected. Switch to Increased by/Decreased by with a real threshold instead of Changed.
The watch shows as failing rather than alerting	That's a connection problem, not a row count problem. Check the connection's Test result.

Row count vs. A value

Use Row count when what matters is how many rows came back. Use A value with a threshold when what matters is a specific number inside those rows, a sum, a percentage, a single status flag.

Picking a check interval that fits the job

An hourly ingestion table fits a 1h check well. A table that only gets one batch a day doesn't need checking every 5 minutes, that just adds noise and unnecessary query load. Match Check every to how often the underlying process actually runs, not to how anxious you feel about it.

A third worked example: Salesforce sync verification

After a Salesforce-to-warehouse sync job, watch the destination table's row count with Changed and a Check every set just after the sync's usual finish time. If the sync silently fails partway through, the row count for that day stays short of what a normal sync produces, and Changed catches that as reliably as it would catch an unexpected spike.

Get alerted when a row count changes.