Dataobservability

TABLEAU DATA QUALITY

Tableau Data Quality Dashboard, Warnings and Checks for the Warehouse Behind Your Vizzes

The only data quality warning Tableau raises on its own fires when a refresh job fails, and disappears when the job succeeds. Freshness, volume, schema, and distribution monitoring on the warehouse tables behind every published data source, read only, with alerts in Slack and PagerDuty, from 99 dollars a month.

See pricing

14-day trial, no credit card, read-only connection

SNOWFLAKE · PROD
247 tables |
Break a monitor:

Alerted #data-eng 0.8s ago.

Downstream impact · consumers at risk

INCIDENT #1042 OPEN · owner @you

Does Tableau have data quality checks?

Tableau has data quality warnings, and they are labels rather than checks. Tableau documents two kinds. A manual warning is a message a person writes and attaches to an asset, and you have to be a server or site administrator, or hold the Overwrite capability, to set one. A monitoring warning is the automatic kind, and Tableau states its trigger plainly: it adds the warning when an extract refresh or flow run fails, and removes it when the run succeeds. So the automatic signal describes the job, not the data. A refresh that finishes cleanly while loading half the rows, yesterday's rows, or a column that quietly changed type produces no warning at all. Both kinds require Tableau Catalog, which is licensed through Data Management, and since September 16, 2024 Data Management is no longer sold as an independent add-on. The actual checks have to run upstream, on the warehouse tables the extracts read from, which is where a wrong number can still be caught before a viz renders it.

Last updated September 2026

// COMPARE

Side by side

Tableau data quality compared

Swipe to see all columns →

Route to Tableau data quality What it catches What you build and operate Documented limit
Manual data quality warning Whatever a person types into it, shown in the Data Details pane, in list views, and beside the data source in Tableau Desktop Somebody has to notice the problem first, write the warning, and remember to clear it once the data is fixed Requires Data Management. You must be a server or site administrator, or have the Overwrite capability for the asset. Nothing about the data itself triggers it
Monitoring data quality warning An extract refresh or a flow run that failed Nothing beyond turning the site setting on Tableau adds the warning when the refresh or flow fails and removes it when the run succeeds, so a job that succeeds with wrong data produces no warning. Not displayed for extract refreshes that use Tableau Bridge. Off on sites that existed before the setting shipped
Data driven alert A numeric threshold crossed on a published view The view, the measure, the threshold, and a recipient list, per alert Requires a continuous numeric axis of any chart other than a Gantt chart or a map. Numeric bins and discrete numeric axes are not supported, and story points cannot carry an alert
Data freshness policy Nothing. It sets how often cached query results are refreshed The policy, set per workbook Tableau Cloud refreshes cached data every 12 hours by default. Not available in Tableau Desktop or for workbooks that use extract and file based data sources, and the documentation describes no alert of any kind
Tableau Catalog lineage and impact analysis Which workbooks and fields depend on a column, so you can email the affected authors Nothing beyond the license and the indexing time Requires Data Management. Catalog enforces a timeout limit and a node limit, and users see Showing partial results, Request time limit exceeded, or NODE_LIMIT_EXCEEDED, on large results
Warehouse level monitoring, this product Freshness, volume, schema change, and distribution on the tables the extracts read from, against a learned baseline A read only warehouse user and a decision about which tables page somebody Watches Snowflake, BigQuery, Databricks, and Redshift. It does not watch the Tableau site, so refresh job health stays where it belongs, in Tableau

Positioning and pricing models are summarized in good faith from each vendor's public pages, September 2026. Verify current terms with the vendor.

// CAPABILITY

What you get

What warehouse level monitoring adds underneath Tableau

The one warning Tableau raises by itself is a job status

This is the sharpest gap on the page and Tableau documents it in one sentence: it automatically adds a quality warning to the asset when an extract refresh or flow run fails, and it automatically removes the warning when the refresh or flow run succeeds. Read that as a monitoring specification and the coverage becomes obvious. It fires on infrastructure failure and clears on infrastructure success. The failure mode analytics teams actually lose days to is the opposite shape: the job ran, the job passed, and the data it loaded was wrong. Row counts collapsed because an upstream filter changed. A join started dropping records. A currency column arrived as text. Every one of those produces a green refresh, and therefore no warning. Watching the source tables directly is the only way that class of problem gets caught, because the check has to look at the data instead of the exit code.

A warning nobody sets is a warning nobody sees

Manual warnings work exactly as advertised, and their weakness is the human loop they sit inside. Somebody has to discover the problem, decide it is worth flagging, have the administrator rights or the Overwrite capability to flag it, write the message, and then come back later and take it down. In practice the flag goes up during an incident that people already know about, and it stays up for weeks after the fix because clearing it is nobody's job. The information a viewer needs, which is that this number is wrong right now, is exactly the information the manual system is worst at delivering, because it depends on the person who already knows.

Freshness has no alert path anywhere in Tableau

Trace the freshness question through each Tableau feature and it dead ends every time. Data driven alerts require a continuous numeric axis, so a last loaded timestamp cannot carry one. The data freshness policy sounds like the answer and is not: it controls how often cached query results are refreshed, Tableau Cloud defaults to every 12 hours, and it is not available for workbooks that use extract and file based data sources, which is most of them. Monitoring warnings only fire when the refresh fails, so a table that stopped receiving upstream data while the refresh kept succeeding stays silent. The one place a stale table is visible as a fact is the warehouse, where the maximum event timestamp can be compared against what normal looks like for that table on that day of the week.

The feature is priced per seat, not per table

Since September 16, 2024 Data Management is no longer available as an independent add-on. To get Tableau Catalog, and with it data quality warnings, the deployment moves to Tableau Enterprise, Tableau Cloud Plus, or the Tableau Plus bundle on Cloud, or to Tableau Enterprise or Tableau Server Plus on Server. Tableau Enterprise is sold on a per user role based model across Creators, Explorers, and Viewers, and each role based license includes Data Management. That means the cost of turning on data quality warnings scales with how many people look at dashboards, and not one dollar of it buys an additional check. Adding fifty viewers who never touch a warning raises the bill; adding five hundred tables to monitor does not lower it.

Detection before the extract, not after

A monitor that sits on the warehouse table runs on its own schedule, independent of the extract. When the orders table stops loading at 02:00, the alert goes out at 02:15, before the 06:00 refresh copies the incomplete state into an extract and before the first person opens the dashboard. Inside Tableau, the earliest possible signal is the refresh outcome, which by definition arrives after the bad data has already been pulled in. That ordering is the whole argument, and it does not depend on which Tableau edition anybody bought.

// 4 STEPS

How it works

From connected to caught

01

Point the monitoring at the warehouse, not the Tableau site

Connect Snowflake, BigQuery, Databricks, or Redshift with a read only user and let it inventory the schemas your published data sources read from. This is deliberately upstream of Tableau: no site administrator role, no personal access token on the tenant, no change to a single workbook. Extract and flow health stays in Tableau where it is already visible, and data correctness moves to the layer where it can be judged before a viz ever renders it.

02

Start from the tables your published data sources read

Most warehouses hold far more tables than any dashboard touches. Begin with the marts and views your published data sources and live connections query, which is usually a short list, and make those the first monitored set. Lineage then walks upstream and shows the tables those depend on, which is the real set that can break a dashboard. If you already run Tableau Catalog, its impact analysis answers the mirror image question inside Tableau, telling you which workbooks depend on a given field once you know the field is broken.

03

Set the checks that match how each table is loaded

A table appended hourly by a streaming job needs a freshness window measured in minutes and a volume band around the usual arrival rate. A dimension rebuilt nightly needs a schema change check more than it needs a freshness check. Baselines are learned from history rather than typed in, so the first week is calibration and the thresholds after that reflect what that table normally does, including the weekday and weekend split that trips most hand written rules.

04

Route the alert to where the on call already is

Alerts go to Slack and PagerDuty, grouped by root cause so one late upstream table produces one incident rather than one per affected mart. Teams that also want the banner visible inside Tableau have a documented path: Tableau exposes a REST API that can enable and modify both the manual and the monitoring kinds of data quality warning, so the same automation that opens the incident can raise the warning on the affected data source and clear it when the check passes again.

What a Tableau data quality warning actually is

A data quality warning in Tableau is a label attached to an asset, not a rule that evaluates anything. Tableau documents the feature as part of Tableau Catalog, which is licensed through Data Management, and describes the available types as Warning, Deprecated, Stale data, and Under maintenance, with administrators able to extend that list by customizing data labels. You can set several different warnings on one asset, and you can mark a warning as high visibility, which Tableau says makes it appear more urgent and appear in more places. Once set, the warning shows up in the Data Details pane, in list views, on asset pages, and next to the data source in Tableau Desktop, which is genuinely useful communication. What none of that describes is a condition. There is no threshold, no expression, no schedule, and no evaluation. The label says what a person decided to say, until a person decides to change it. That distinction gets lost because the feature is named for the problem it communicates rather than for what it does, and teams comparing tools put a check mark next to Tableau for data quality monitoring on the strength of the name.

The monitoring warning fires on the job, not on the data

Tableau does provide one warning that appears without a human, and its specification is a single documented sentence: Tableau automatically adds a quality warning to the asset when an extract refresh or flow run fails, and later, if the extract refresh or flow run succeeds, Tableau automatically removes the quality warning. Both halves matter. The trigger is a failed job. The clear condition is a successful job. Nothing in that loop reads a row. Consider the ordinary Monday morning incident. An upstream system changed a filter over the weekend and the fact table now loads 40 percent of its usual rows. The extract refresh reads the table, finds rows, writes them, and exits zero. Under Tableau monitoring warnings that is a healthy asset, and the dashboard shows a revenue chart that is 60 percent short with no indication anything is wrong. Now consider the reverse: a refresh fails at 03:00 because a credential expired, the warning appears, an engineer rotates the credential, the next run succeeds, and the warning clears itself. That second case is the one the feature was built for, and it is an operations signal that most teams already receive from refresh failure notifications. There is also a documented hole in the automatic path. Tableau states that data quality warning notifications are not displayed for extract refreshes that use Tableau Bridge, which is the component many Tableau Cloud customers use to reach data behind their own firewall. And the site setting is on by default only for new sites; sites that existed before the change have it turned off, so a long running deployment may have no automatic warnings at all and nobody has noticed.

Why a data quality dashboard built in Tableau checks the data after it is already wrong

Building a data quality dashboard in Tableau is a common and reasonable project. The usual shape is a workbook over a results table or a set of profiling queries, with null rates, row counts, duplicate counts, and a last loaded timestamp per table, often with a traffic light per rule. It communicates well, executives like it, and it belongs in the stack. The limitation is structural rather than aesthetic, and it comes down to when the numbers are computed. The dashboard renders whatever its data source last pulled. If the workbook uses an extract, the panel is as fresh as the last refresh, which means the worst case is that the extract refresh itself failed and the quality dashboard is now showing yesterday's healthy numbers while today's data is broken. If the workbook uses a live connection, the numbers are current but only while somebody is looking at the screen, and nobody is looking at 03:00. Turning that dashboard into an alert runs into the data driven alert rules: alerts require a continuous numeric axis of a chart other than a Gantt chart or a map, numeric bins and discrete numeric axes are not supported, and story points cannot carry one. You can work within those rules by computing hours since last load as a continuous measure and alerting when it crosses a threshold, and plenty of teams do. It works right up to the case that matters most, because if the upstream load stops and the measure stops updating with it, the number sits frozen below the threshold and no alert ever fires. A quality dashboard in Tableau is a good reporting surface for checks that ran somewhere else. It is a poor place for the checks themselves to live.

Data freshness policy is a cache setting, and the name costs teams time

Search for Tableau data freshness and the documentation puts a feature called the data freshness policy in front of you, which sounds exactly like a way to answer the question of whether your data is stale. It is not that. The policy governs how often Tableau refreshes the cached results of the queries used to fetch data, so subsequent visits can reuse and return that cached data faster. Tableau Cloud refreshes cached data every 12 hours by default, and a workbook owner can change it to always live, to a specified interval, or to specific scheduled times. Every option in that list is about cache invalidation. None of them evaluates the data or notifies anybody, and the documentation describes no alerting behavior at all. There is a further constraint that removes it from the conversation for most deployments: data freshness policies are not available in Tableau Desktop or for workbooks that use extract and file based data sources. Extracts are the dominant pattern in Tableau, so the feature that carries the word freshness in its name does not apply to the majority of the workbooks people want freshness answers about. Genuine freshness monitoring asks a different question, against the source: what is the maximum event timestamp in this table right now, how far behind is it compared with what is normal for this table at this hour, and who should hear about it if the gap is unusual. That question is answerable in the warehouse and is not answerable from a cache policy.

What the 2024 licensing change did to the build versus buy math

This is the part of the evaluation that most often turns a technical comparison into a procurement conversation. Tableau documents that as of September 16, 2024, Data Management is no longer available as an independent add-on option. It is now reached through Tableau Enterprise, Tableau Cloud Plus, or the Tableau Plus bundle on Tableau Cloud, or through Tableau Enterprise or Tableau Server Plus on Tableau Server. Data Management is what contains Tableau Catalog, Tableau Prep Conductor, virtual connections, and data policies, and Catalog is what contains data quality warnings. So the chain from I would like a stale data label on this data source to the invoice runs through an edition change for the whole deployment. Tableau also documents how Enterprise is sold: on a per user role based licensing model, including Creators, Explorers, and Viewers, with each role based license including Data Management and Advanced Management. That pricing shape is worth sitting with, because it is unusual among the native data quality features. Snowflake bills data quality monitoring by serverless compute per run. Google bills Dataplex quality scans by data compute units with scan frequency as a priced factor. Databricks bills the compute the monitor consumes. All of those meter the checking. Tableau meters the audience. The bill moves when the number of people with logins moves, and it does not move at all when you add or remove the thing being checked. A company with four hundred viewers and a dozen important tables pays for four hundred viewers. If the requirement is genuinely tell me when these twelve tables break, an edition upgrade priced on headcount is an expensive route to that answer, and it is worth pricing both options before the feature comparison starts rather than after.

Where Tableau Catalog lineage stops

Tableau Catalog is a real asset and the honest comparison should say so. It discovers and indexes the content on a Tableau site, including workbooks, data sources, sheets, metrics, and flows, and it lets you trace the fields a workbook depends on and see which content depends on particular columns. Its impact analysis answers the question every analytics team asks before a schema change, which is what breaks if I alter this, and it can notify the impacted Tableau authors by email. That is column level dependency information inside Tableau, and it is the best thing in the Data Management bundle. The limits are about scope and scale. Scope first: Catalog lineage is a map of the Tableau estate and the connections into it. It does not follow a column back through the transformation graph inside the warehouse, so when a mart column goes wrong it tells you which dashboards are affected downstream but not which upstream model produced the bad value. Scale second, and Tableau documents this explicitly. Catalog enforces both a timeout limit and a node limit so that tasks returning large result sets do not consume all system resources. When a task hits them, users see Showing partial results, Request time limit exceeded. Try again later, or NODE_LIMIT_EXCEEDED. Partial lineage results are a specific hazard in impact analysis, because the answer looks like a complete list of affected workbooks and is not, and nothing in the message tells you how much is missing. The two systems answer different halves of the same question. Catalog is strong on Tableau side dependencies. Warehouse level lineage covers the transformation path that produced the value in the first place, and the pairing of the two is what actually shortens a root cause investigation.

// FAQ

Questions buyers ask

Tableau data quality FAQ

How do you check data quality in Tableau?

There are three practical routes and they cover different moments. While preparing data, Tableau Prep and the Tableau Desktop data pane let you profile columns and inspect distributions by eye, which is a design time activity. After publishing, you can attach data quality warnings to assets, which requires Data Management and is a label a person writes rather than a check that evaluates anything, and you can set data driven alerts on numeric thresholds in published views. For anything that has to run unattended, including freshness and row volume, the check has to live upstream in the warehouse, because the only warning Tableau raises on its own is triggered by a failed refresh or flow run.

What are data quality warnings in Tableau?

Data quality warnings are labels you attach to a Tableau asset such as a data source, table, or database, and they are a feature of Tableau Catalog, part of the Data Management offering. Tableau supports two kinds. Manual warnings are written by a person who must be a server or site administrator or hold the Overwrite capability. Monitoring warnings are added automatically when an extract refresh or flow run fails and removed automatically when it succeeds. The built in types are Warning, Deprecated, Stale data, and Under maintenance.

Do you need Data Management to use data quality warnings in Tableau?

Yes. Data quality warnings are part of Tableau Catalog, which is licensed through Data Management. Tableau documents that as of September 16, 2024, Data Management is no longer available as an independent add-on option, so it now arrives with Tableau Enterprise, Tableau Cloud Plus, or the Tableau Plus bundle on Tableau Cloud, or with Tableau Enterprise or Tableau Server Plus on Tableau Server. Because Tableau Enterprise is licensed per user across Creators, Explorers, and Viewers, the cost of the feature scales with the number of people on the site rather than with the number of tables you want to watch.

Can Tableau alert you when data is stale?

Not directly, and this is the most common gap teams find late. Data driven alerts require a continuous numeric axis, so a last loaded timestamp cannot carry an alert on its own. The data freshness policy is a cache control that sets how often cached query results are refreshed and has no alerting behavior in the documentation. Monitoring data quality warnings only appear when a refresh or flow run fails, so a table that stopped receiving upstream data while the refresh kept succeeding raises nothing. The common workaround is to compute hours since last load as a numeric measure and alert on that, which breaks in the exact case it is meant to catch, because a frozen measure never crosses the threshold.

How do you build a data quality dashboard in Tableau?

The usual approach is a workbook over a results table that holds one row per check run, with null rates, duplicate counts, row counts, and a last loaded timestamp per table, then a traffic light view by domain or owner. It is a good reporting surface. What it cannot be is the detection layer, because an extract backed dashboard is only as current as its last refresh, a live connection is only evaluated while somebody is looking at it, and turning it into an alert runs into the rule that alerts need a continuous numeric axis. Run the checks on a schedule against the warehouse, then point the Tableau dashboard at the results table if you want the executive view.

What is the Tableau data freshness policy?

It is a caching setting, not a monitoring feature. Tableau caches the results of the queries used to fetch data so that later visits can reuse that cached data, and the freshness policy controls how often the cache is refreshed. Tableau Cloud refreshes cached data every 12 hours by default, and the options are the site default, always live, ensuring data is fresh every chosen interval, or ensuring data is fresh at specific scheduled times. It does not check whether the underlying data arrived, and Tableau notes that freshness policies are not available in Tableau Desktop or for workbooks that use extract and file based data sources.

Does Tableau have column level lineage?

Tableau Catalog provides column level dependency information inside the Tableau estate. You can trace the fields a workbook depends on and see which workbooks and other Tableau content depend on particular columns or fields, and impact analysis can email the affected authors before a change. What it does not do is follow a column back through the transformation graph in the warehouse to the model that produced it. Catalog also enforces a documented timeout limit and node limit, and on large results users see a partial results message or NODE_LIMIT_EXCEEDED, so an impact analysis answer can be incomplete without saying so.

What is the difference between a Tableau data quality warning and data quality monitoring?

A warning is a label attached to an asset. Monitoring is a check that runs on a schedule, evaluates a condition against the data, and tells somebody when the result is abnormal. Tableau warnings communicate a conclusion that either a person reached or a failed job implied, which is why the automatic ones appear on refresh failure and clear on refresh success. Monitoring is what produces the conclusion in the first place: comparing today's freshness, row volume, schema, and value distribution for a table against what that table normally does, and raising an incident when the difference is real.

Catch broken data before your stakeholders do

Connect your warehouse and get tableau data quality live from one read-only connection. Transparent pricing, no credit card.