Data Studio problems have short diagnoses, because every materialization is logged: each dataset, data model and archive rule carries an append-only run history with statuses, row counts and error messages. The method on this page is always the same — find the object's history, read the newest entries, and let them tell you which of the usual causes you have. Guessing is never necessary; the trail is on the object.
Start diagnosis from the newest run history, then follow lineage upstream and downstream: dataset refresh, model build, source entity, archive rule and target table. Compare timestamps, row counts and errors at each hand-off rather than rerunning jobs blindly.
A dataset is stale
Work down the chain from the dataset's Refresh History tab:
- No runs at all, or nothing recent. The schedule never fires: the dataset is inactive, the schedule field is blank (manual-only), or the cron expression is invalid — invalid expressions are skipped silently, with no error anywhere. The scheduling rules list all the eligibility gates.
- The newest run is Failed. Read its error message. Warehouse connectivity failures heal on retry — and the schedule retries failed objects automatically. SQL errors in expressions do not; fix the definition, Validate, and compile once manually.
- Runs succeed but the data is older than expected. The schedule's cadence is the freshness — remember cron is evaluated in UTC, so a "daily 3 a.m." schedule may be firing in the middle of your business day or eight hours later than you assumed.
- The dataset is fresh, but a downstream surface is not. A dashboard or embedded BI report has its own consumption step: embedded BI models need their own refresh after the dataset's table updates.
- The dataset is fresh but the model is not. A dataset rebuild reads the model's materialized table, so a stale model gives a fresh-looking dataset with old numbers. Check the model's Build History the same way.
Rows are missing from a dataset
Missing rows were excluded somewhere on the way in. Check the gates in the order the data passes them:
- The data model's filters and joins. Model filters exclude rows at the source, and an inner join drops every row without a match — the classic silent absence. If orders without a customer vanish, the customer join being inner instead of left is the first suspect.
- The dataset's filters. Build-time filters are ANDed into the compile; excluded rows are genuinely absent from the table. Preview shows the active filters and the generated SQL, which settles what the build actually asked for.
- Aggregation. A dataset's rows are its dimension combinations. A "missing" record may be present but folded into an aggregate row — check whether the grain you expect matches the dimensions the dataset defines.
- Archival. If an archive rule moved the rows out of the operational database, a model sourcing only the live entity no longer sees them. The rule's run history shows what moved and when; the fix is a model that also reads the archive table.
- Row security is not the cause of missing rows in the table. Security rules do not remove rows from the materialized data — if an audience is missing rows in a consuming surface, that is the surface's scoping, not the build; see row-level security for what rules do and do not guarantee.
A compile or build fails — or refuses to start
- Refused with validation errors, and no history entry. Compilation only starts once validation passes, so a refused compile leaves no run. Run Validate and fix what it lists — the most common error is an expression referencing a column the bound data model does not publish. Use the model's output column names, not the operational entity's field labels; the editors' pick lists exist to make that automatic.
- Fails with a connectivity error. The analytics warehouse was unreachable; nothing was written. The failed run stays in history with the message. Retry later — scheduled objects retry on their own.
- Fails with a SQL error. Dimension, measure and filter expressions are warehouse SQL, executed as written. Preview the generated SQL, find the offending expression, fix it, validate, recompile.
- The workspace warns "Data Model schema is unavailable". The dataset is bound, but the model's schema could not be loaded — authoring guidance degrades to free text, while compile-time validation still runs. Confirm the bound model still exists and publishes columns.
Records disappeared from the application
When users report records gone from lists — not from a dataset, from the application — and nobody deleted them, check the archive rules before the recycle bin. An archive run moves qualifying rows out of the operational database entirely: they stop appearing in lists, live reports and API queries, and they are not in the recycle bin, because they were never deleted. The rule's run history shows exactly when a run succeeded and how many rows it moved; if the wrong rows qualified, the rule's condition formula was too broad — tighten it, and recover the affected rows by copying them back from the warehouse table (an operator-level task; there is no in-product restore). The deleted-versus-archived distinction is laid out in the data lifecycle.
Common questions
Where do I see why a run failed?
On the object's history: the Refresh History tab for datasets, Build History for data models, the History row action for archive rules. Every failed run carries the underlying error message, and the histories are append-only, so the evidence survives the fix. The one silence to know about: a dataset or model refused at validation leaves no run — the findings are in the Validate dialog instead.
A run says Success with zero rows — is that a failure?
Usually not. Zero is a legitimate output: nothing qualified for an archive rule's window, or a dataset's filters excluded everything currently in the model. It becomes a symptom only when you expected rows — then read it as "the definition matched nothing" and check the filters, joins and cutoffs rather than the execution.
The numbers are wrong in every report at once — where do I start?
At the model, not the reports. When every consumer of a dataset agrees on the same wrong number, the shared definition produced it: check the dataset's measures and filters, then the data model's joins and columns, then the freshness of both materializations. This is the intended failure mode of governed analytics — one place to fix instead of ten — and the histories tell you whether the definition or the data changed underneath it.