Numbers stop changing without warning
The report keeps loading with unchanged figures after an earlier step fails. Its familiar layout makes old values look as dependable as data from a recent successful refresh.
Data analysis & dashboards
Your dashboard loads normally, but figures stopped updating. A page timestamp may make them look current even after a failed refresh. We trace the data path and show its age, so staff can tell a recent page from recent data.
Discuss this problemWe follow one affected number from the source, through each processing step, to the dashboard. Then we compare scheduled runs with proof that they actually finished, including numbers that combine several inputs. Your report owner agrees when old values can stay visible and what should happen when data is older than expected. Where it's in scope, we repair the refresh fault we verified, then test the stale-data labels and owner alerts. Recovery includes confirming the data boundary (the latest point your processed data covers), not merely loading the report again.
The report keeps loading with unchanged figures after an earlier step fails. Its familiar layout makes old values look as dependable as data from a recent successful refresh.
A displayed timestamp moves forward when the page loads, not when source data is processed. Staff read it as proof of freshness that the number underneath does not actually have.
One input refreshes while another stays old, yet the combined number looks current. The recent source hides the missing update you need before you can trust the final figure for decisions.
We compare timestamps at each stage for the affected number: pulling the data, processing it and publishing it. The chain shows where current source records stopped reaching the dashboard and which dependency needs attention.
We look for proof of successful completion, not only the configured schedule. A timer firing or a page rendering can look healthy while the dataset behind the report stays unchanged.
For combined numbers, we map which sources each one depends on and examine what happens in a partial refresh. A good update from one source must not imply that every required input is current.
We display the latest data boundary that was successfully processed for the source or measure. Labels explain what that time means, so a page-load timestamp does not suggest freshness the data can't support.
A failed refresh becomes visible to an assigned owner who can act on it. Alerts keep the failing reference and a safe way to inspect it, and we correct the verified fault within scope.
We apply the agreed publishing checks when only part of the source data has arrived. Combined values keep a clear stale label or approved restriction until the data needed to treat them as current has actually arrived.
Only if its meaning is accurate. We trace whether it reflects source processing, dataset publishing or page rendering. The label you choose should describe the data used for the measure, not merely the time someone opened the dashboard.
Yes, that can be appropriate if the report owner approves a clear stale label. Some decisions may need stronger restrictions when inputs are incomplete. We agree on that behavior and test it, so we do not automatically clear every number after a missed refresh.
Not by itself, because visibility and the source fix are separate parts of the work. We investigate the failure and find whether access, data pulling or processing needs repair. Any outside dependency beyond the agreed scope gets documented, so a freshness label does not hide an unresolved refresh fault.
Share your dashboard and source platforms, plus one number that stopped changing, with private details removed. Include its expected refresh interval and last known current value so we can trace where the update failed.
Explore Data Analysis More problems in Data analysis & dashboards
Tell us about your project and we'll get back to you within 24 hours.