Refresh failures and stale data

Why this matters

A report that was correct yesterday can be wrong today without anyone touching it, because the data under it stopped arriving, arrived late, or arrived in a different shape. The most damaging version is the quiet one: the dashboard opens normally, the charts render, the numbers look reasonable, and they are two weeks old.

The exam's objective includes solving reporting issues. This lesson covers how stale data goes unnoticed, freshness checks, the common causes of refresh failures, alerting, and what to do when users have already seen wrong numbers.

The lesson

How a report shows stale data without an error

Most reports do not fail visibly when their data stops updating. A BI dashboard that imports data on a schedule keeps showing the last successful import if a refresh fails. A report built on a table that a pipeline stopped loading shows whatever the table last contained. A scheduled email keeps arriving, with the same numbers each day.

Stale data is hard to spot because it is plausible: yesterday's figures look like today's. It is most often noticed by someone who knows what should have changed, such as a sales manager who closed a large deal that does not appear.

Partial refreshes are worse still. If a load stops halfway, the report may show this month's data for some regions and not others, or a total that is lower than it should be but not obviously wrong. A sudden drop in the latest period is often a sign of incomplete data rather than a real decline, which is why analysts treat the most recent period with caution until the data is confirmed complete.

Last-refreshed timestamps and freshness checks

The first defence is visibility: every report and dashboard should show when its data was last refreshed, prominently, in words a reader will notice, such as "Data as of 25 September 2025, 06:00". It lets users judge for themselves whether the numbers are current.

A timestamp only helps if it is accurate. It should record when the data was last updated, meaning the time of the latest source record or the last successful load, not merely when the report was last opened or recalculated.

The second defence is automated freshness checks. For each table or source, record the time of the most recent load or the latest record, define how old is acceptable, such as "no more than 26 hours for a daily load", and check it on a schedule. A table that breaches its freshness limit triggers an alert before anyone reads a stale report.

Freshness checks pair naturally with volume checks: a load that ran on time but delivered far fewer rows than usual is as much a problem as a load that did not run.

Broken connections, schema changes and renamed fields

Refreshes fail for a limited number of reasons, and knowing them speeds diagnosis.

• Connection and credential failures: a password expired, a service account was disabled, a server moved, a firewall rule changed, or a token lapsed. These are among the most common causes, and they often follow routine security changes elsewhere.
• Schema changes in the source: a column renamed, removed, or changed type; a table split or merged. A report that selects a column by name fails, or worse, silently picks up a similarly named column.
• Source changes: a new system replaces an old one, a file arrives in a new location or format, or an API version is retired.
• Upstream failures: an earlier pipeline step failed, so the report refreshed successfully from tables that were not updated.
• Capacity and timeouts: data grew until the refresh no longer finishes within its time limit.

Diagnosis follows the data backwards: check the report's refresh log, then the tables it reads and when they were last loaded, then the pipeline that loads them, then the source. The failing step is usually the first place where the timestamps stop.

Alerting on a failed refresh

Failures should be found by a system, not by a reader. Alerting turns refresh problems into notifications sent to the people who can fix them.

Effective alerting covers:

• Hard failures: a refresh or pipeline job that errored or did not run.
• Freshness breaches: data older than its agreed limit.
• Volume anomalies: far fewer or far more rows than normal.
• Validation failures: control totals that do not reconcile.

Alerts should go to a named owner or team with the ability to act, include enough detail to start diagnosis, and be tuned so they fire on real problems. Alerts that fire constantly on normal variation are ignored, and an ignored alert system is no better than none. Where a failure affects readers, the alert should also prompt a notice on the report itself.

Telling users when numbers are wrong

When a report has shown wrong or stale numbers, users need to be told, even when it is uncomfortable. Decisions may already have been made on those figures.

A good response includes:

• Flagging the report immediately, with a banner or notice that the data is incomplete or under review, rather than leaving it looking normal.
• Notifying the known users, especially those likely to have acted on it, with what was wrong, which period and figures were affected, and when it will be fixed.
• Correcting the data and re-running the report, then confirming the fix with validation checks.
• Recording the incident: the cause, the impact and the change made to prevent it recurring, such as a new freshness check.

Being open about errors protects trust. A report whose owners announce and fix problems is more credible than one that has never admitted any, because every report has them eventually.