Data Quality Alerts for Power BI and Tableau: Best Tools for Freshness and Null Rate Monitoring

If you want an alert when a number on a dashboard is wrong, the alert has to live upstream of the dashboard. Power BI and Tableau can both tell you when their own refresh job failed, and neither can tell you that a refresh succeeded against a table that stopped loading three days ago. That second case is the one that reaches an executive, because nothing errored and every status light is green.

This article covers what each BI tool can genuinely alert on, the documented limits that decide it, and how to get freshness and null rate alerts for each warehouse column without building a monitoring system inside a reporting tool. For the full comparison of the native options, see our Power BI data quality breakdown.

Can Power BI alert on data quality?

Within narrow limits. Microsoft documents that data alerts can only be set on tiles pinned from report visuals, and only on gauges, KPIs, and cards. They work only with numeric data types, and they are explicitly not supported for card tiles with date or time measures. Only the person who created an alert can see it, even on a shared dashboard, and you are capped at 250 alerts across all your models.

Read that list again with a data engineer's eye, because the consequence is bigger than it looks. A last loaded timestamp is a date measure. Alerts do not work on date measures. So the single most common data failure, a table that quietly stopped loading, is the one condition you cannot put a Power BI alert on.

The usual workaround is to compute hours since last load as a number and alert on that. It works right up until the moment it matters: when the upstream table stops loading, the measure that counts hours since last load stops updating too, so it sits at its last good value and never crosses the threshold. The check and the thing being checked share a failure mode.

Do Tableau data quality warnings monitor anything automatically?

Mostly no. Tableau data quality warnings are part of Tableau Catalog, which ships in the Data Management offering for Tableau Server and Tableau Cloud, so it is a paid add on. The built in types are Warning, Deprecated, Stale data, and Under maintenance, and to set one you must be a server or site administrator or hold the Overwrite capability for the asset.

The word automatic does appear, but narrowly: Tableau adds a warning when an extract refresh or a flow run fails, and removes it when the operation succeeds. Everything else is a human applying a badge because they already know something is wrong. The Stale data warning, despite the name, is usually a label somebody set by hand rather than a detection.

So Tableau draws the same boundary Power BI does. It reports on the health of its own jobs. It does not assess whether the table underneath is correct.

What each layer can actually alert on

Which tools surface freshness and null rates for each warehouse column?

This is the request that comes up most often, usually phrased as wanting a reporting tool that can show data quality metrics per column. The honest answer is that BI tools are the wrong layer to compute them in, and a good layer to display them in.

Computing per column freshness and null rates inside a semantic model means importing profiling queries as just another table, on the same refresh schedule, from the same warehouse you are trying to check. When that warehouse goes stale, your quality metrics go stale with it and the dashboard shows a confident green tick calculated from yesterday. Power Query's own profiling does not fill the gap either: column quality and column profile default to the first 1,000 rows, and the switch to the entire data set is a session level toggle in the editor, so it is a design time preview rather than something that runs after publish.

The arrangement that holds up is to compute in the warehouse and display in BI. A monitoring layer connects read only, reads table metadata and cheap aggregates, keeps a history per table and per column, and pushes an alert the moment a load time, a row count, a null rate, or a column type moves outside its own learned range. Then, if your team lives in dashboards, you point a report at the incident history so people can see trends without leaving the tool they already use. The alert does not depend on anybody opening it, and the display does not have to be correct in real time.

Turning dbt tests into dashboard alerts

Teams that already run dbt often ask whether the test results can drive BI alerts directly. They can, with a caveat worth knowing before you build the pipeline. dbt's notification triggers are job run outcomes: succeeds, warns, fails, is canceled. They are not per model or per test events, and they are configured per recipient rather than per job. So a job with two hundred models that fails one not_null test sends one message saying the run failed.

The other thing to check is what happens to the failing rows. dbt can write them out with store_failures, but the documentation is explicit that a test result always replaces the previous failures for the same test, into a schema suffixed dbt_test__audit. It is a snapshot, not a history. Without history there is no distribution, without a distribution there is no baseline, and every threshold you set ends up hand chosen and then quietly out of date.

The practical build is: keep dbt tests for invariants that only your business knows, route their run outcomes to Slack, and let a monitoring layer keep the metric history and own freshness, volume, schema, and distribution across every table, including the ones nobody wrote a test for. Our dbt observability page goes through where each side of that split earns its keep.

How do you get an alert when a Power BI report goes stale?

Set the alert on the table, not the report. In the Power BI service you can add contacts to a semantic model's scheduled refresh so failures get emailed, and that is worth turning on, but it only fires when a refresh errors. For staleness you need something comparing each source table's last load time against what is normal for that table, including the detail that a mart loaded hourly on weekdays and never on Sunday is not broken on Sunday.

Once that check sits upstream, the sequence flips in a useful way. The monitoring fires at 3am when the load did not arrive, the owning team sees it in Slack before the 6am refresh runs, and the report either gets fixed or gets held. Compare that to the default path, where the refresh publishes yesterday's numbers, the dashboard looks fine, and the problem surfaces when somebody senior asks why revenue fell off a cliff. By then the figure has usually been pasted into a deck, and anything built from those dashboards into a board presentation carries the bad number with it.

A workable setup for a team running both

Plenty of US analytics teams run Power BI for finance and operations and Tableau for a product or commercial team, on the same warehouse. Duplicating quality logic in both is how you end up with two sets of thresholds that disagree. A cleaner split:

• In the warehouse: freshness, volume, schema drift, and distribution on every table that feeds a report, with baselines learned per table and alerts routed to the team that owns each schema.
• In dbt: the assertions that encode business rules, such as a status field only ever holding four values or a foreign key that must resolve. Keep the list finite.
• In Power BI and Tableau: refresh failure notifications, since those are genuinely about the BI job, plus a small number of numeric alerts on the handful of headline KPIs where a sudden move is worth a message.
• In a report: the incident history and per table trends, for the people who prefer to see it where they already work.

The test of whether the setup works is simple. Pick a table, ask what would happen if it silently stopped loading tonight, and follow the chain. If the first person to notice is a stakeholder looking at a chart, the checks are in the wrong layer. Our data quality dashboard page covers what to put on the display side, and pipeline monitoring covers catching the load itself.

Frequently asked

Can Power BI alert on a last refreshed date? No. Microsoft documents that alerts are not supported for card tiles with date or time measures, and that alerts only work with numeric data types. Converting the date to a number of hours works until the source stops updating, at which point the measure freezes at its last value and never crosses the threshold.

How many Power BI alerts can I create? Up to 250 across all your models. They are also private to whoever created them and have no co ownership, so moving one to another person means recreating it, along with any Power Automate flow attached to it.

Does Tableau detect stale data automatically? Only in the sense that it flags a failed extract refresh or flow run. The Stale data warning type is normally applied by an administrator or a user with Overwrite capability, by hand, after somebody has already worked out there is a problem.

How quickly can a BI tool notice a broken table? No faster than its refresh cadence, because alerts only evaluate on refreshed data. Power BI allows eight scheduled refreshes a day on shared capacity and 48 slots on Premium, which puts a floor of roughly three hours on detection in the common case, assuming the refresh itself succeeds on time.