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 — for a schedule saved before cron expressions were checked — the expression is invalid and is skipped. The dataset's Overview shows the next run; no next run means one of these. 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 newest run is Pending. It is waiting for warehouse capacity — the Build queue page (
/analytics/builds) shows the wait reason, such as a used-up daily allowance or a build window that has not opened yet. See Runs can wait for capacity. - Recent numbers are right but older ones are not. An Incremental dataset or model recomputes only its newest periods or days, so a correction dated earlier waits for a full reload. Run Full reload (dataset) or a full rebuild (model), and set a full reload schedule so it happens on its own.
- The dataset is fresh, but a dashboard is not. Dashboard tiles cache their results per viewer for about a minute (the dashboard's designer can lengthen it); reopen the dashboard or use Refresh data once that has passed.
- 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. A model whose After a build is Nothing also leaves its datasets a build behind until their own schedules come round.
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. An archive rule marks the rows it archives as deleted in the operational database, and models skip deleted rows by default. A model that reads the entity's Silver view (
silver.<Entity>) still sees them, because that view also reads the entity's archive table. A model whose source reads the live rows another way does not. The rule's run history shows what was archived and when; the fix is a model that reads the Silver view or the archive table. - Row security, for one audience only. Security rules never remove rows from the table, but dashboard tiles apply them: a viewer sees only the rows of the rules for their roles, and nothing at all if no active rule covers them. If one person sees fewer rows than another, check the dataset's Security tab before the build; see row-level security.
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 copies qualifying rows to the warehouse and then marks them deleted in the operational database: they stop appearing in lists, live reports and API queries, and they are not in the recycle bin, because no user deleted them. The rule's run history shows exactly when a run succeeded and how many rows it archived; if the wrong rows qualified, the rule's condition formula was too broad — tighten it. The rows are still in the database, marked deleted, unless the rule deletes permanently or purges after a number of days, so recovering them is an operator-level database 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.