Key takeaways
- Set refresh cadence from the decision cycle and the cost of stale data, not from what the pipeline can do.
- Measure the full latency chain; the slowest link sets the freshness users actually experience.
- Frequent refresh increases load and failure surface, so match frequency to tolerance.
- Show last refresh time, data-through time, and failure state where users can see them.
On this page
Freshness is a decision requirement
Every dashboard has a freshness requirement whether or not anyone wrote it down. If the viewer assumes the number is current and it is a day old, the dashboard is wrong even when every row is correct.
Ask what decision the number supports and how much staleness changes it. A monthly margin review tolerates a day. A same-day dispatch decision may not. The answer sets a tolerance, and the tolerance sets the schedule.
Map the latency chain
A dashboard's freshness is the sum of its stages: time for the source system to commit a record, the extract interval, transformation time, load time, semantic model refresh, and any cache or scheduled snapshot.
Measure each stage rather than guessing. The extract may run every fifteen minutes but take twenty, so it is always one cycle behind. A cache may add an hour after a successful refresh. Write the chain down with durations; it becomes the explanation when a user asks why the number is late.
Match cadence to the decision cycle
The schedule should follow the rhythm of the work. A daily stand-up needs data that is complete before the meeting, not a continuous stream. A monthly review needs a stable snapshot, not a number that changes while it is being discussed.
The table is a pattern, not a rule. Derive frequency from the decision, then check the cost. A daily refresh used for a monthly meeting is wasted compute; a monthly refresh used for daily dispatch is a broken process.
| Decision rhythm | Sensible refresh | Staleness tolerance | Design note |
|---|---|---|---|
| Monthly review | Daily or weekly | Days | Refresh before the review, not continuously |
| Weekly operations | Daily | One day | Complete before the start of the working day |
| Daily stand-up | Hourly or overnight | Hours | Ensure completion before the meeting |
| Same-day response | Every 15 to 60 minutes | Under an hour | Watch source load and partial loads |
| Live incident | Minutes or streaming | Seconds to minutes | Expensive; reserve for operational need |
Understand the cost of frequency
Each run consumes source capacity, compute, and attention. Hourly refreshes multiply the number of failures, and a failed run at the wrong time leaves users with yesterday's data and no warning. Rate limits on APIs and contention with operational systems are common constraints.
Incremental refresh reduces the volume per run but adds complexity: late-arriving records, deletes, and backfills need explicit handling. A full refresh is simpler and often fast enough for small datasets. Choose based on data volume and correctness risk, not fashion.
Make freshness visible
Show two timestamps, not one: when the dashboard last refreshed successfully, and the latest event time included in the data. They answer different questions. The first says whether the pipeline ran; the second says how current the content is.
Use the viewer's time zone or state the zone explicitly. Add a status indicator when the latest run failed or is delayed, and keep the last good data visible with a warning rather than blanking the page. A dashboard that hides failure teaches users to distrust it.
Design the schedule and the failure path
A refresh schedule is an operational promise. Write it in the dashboard documentation, give it an owner, and review it when the decision rhythm changes. The schedule should be visible to the people who depend on it, not buried in a pipeline configuration.
Plan for the run that does not finish. The checks below cover the operational details that separate a reliable schedule from an optimistic one.
- Stagger refreshes so sources and compute are not hit simultaneously.
- Set alerting on failure and on duration overrun, not only on success.
- Define a retry policy and avoid overlapping runs for the same dataset.
- Schedule around holidays, month-end close, and known source maintenance.
- Document the backfill procedure and who runs it.
- Publish the expected data-through time in plain language.
Frequently asked questions
Is real-time data always better for a dashboard?+
No. Real-time adds cost, complexity, and failure modes, and many decisions do not change within minutes. Use it when the staleness tolerance is genuinely measured in minutes, not because it sounds more capable.
What is the difference between refresh time and data-through time?+
Refresh time is when the pipeline last completed. Data-through time is the latest event included in the data. A dashboard can refresh successfully at noon and still contain data only up to ten in the morning.
Should dashboards refresh at weekends?+
Only if decisions are made then. If nobody acts on weekend data, pause the schedule and make the last refresh timestamp clear. A silent weekend run that fails is harder to detect than a planned pause.
What should users see when a refresh fails?+
The last successful data, a visible warning, the timestamp of that data, and a contact or status link. Blanking the page removes useful context and makes the failure look worse than it is.
Need help applying this?
Get help with Dashboards & BI.
Review the service scope or tell us what you are trying to improve. We will reply with a clear next step.
Free KPI definition templateRelated reading
KPI dashboard design: how to choose metrics that matter
A good KPI dashboard starts with decisions, not charts. Learn how to choose, define, and present metrics people will actually use.
Accessible dashboards: colour, labels, and focus
Design dashboards that stay readable without colour: contrast, redundant encoding, direct labels, keyboard focus, and screen reader structure.