A dashboard is not one timestamp: partial refresh and data freshness
Freshness belongs to each module and its data coverage, not merely to the page reload time. Cross-source measures need an agreed comparable window.
On this page5 sections
A screen fed by several systems needs freshness information for each module. A single “updated just now” label at the bottom does not establish that every metric is current. Keeping usable content when one source fails can be reasonable, but retained values need their original timestamps. A calculation combining sources must also check whether those sources still describe a comparable period.
Separate three different times
Business event time describes when something happened. Source coverage describes how far the supplied data is complete. Page receipt time describes when the browser received the response. In a hypothetical example, sales are complete through 10:00, inventory through 09:45, and both responses reach the browser at 10:01. Calling both cards “10:01 live data” would hide the difference that matters to the reader.
If a source does not provide a coverage field, label the cutoff as unknown or use an explicitly agreed alternative. Do not manufacture it from the browser clock. Server processing completion also does not necessarily establish that every source record has arrived. Name each timestamp according to what it can actually demonstrate, and keep the source or batch identifier available for investigation.
Make module states readable
| Source condition | Display | Evidence retained |
|---|---|---|
| Arrived and within the agreed freshness window | Value with its coverage time | Source and batch |
| Refresh in progress | Readable previous value with an updating state | The previous value's original time |
| Failed, with an earlier value available | Last known value marked stale or failed | Failed module and last successful update |
| First load failed | No usable data yet | Error state, never an invented zero |
Use explicit wording and restrained visual cues rather than making every card flash. One failed module need not erase other completed modules. Equally, the page-level status should not continue to say that all data refreshed successfully. The design should make the partial state visible without forcing users to interpret raw technical errors.
Give cross-source metrics their own update condition
Days of inventory may depend on both stock and sales. If one input is current and the other is stale, recalculation produces a new number without necessarily producing a new trustworthy basis. The project can require a shared cutoff, retain the last consistent batch, or permit a clearly qualified estimate within an agreed tolerance. Choose among these according to the consequences of the decision supported by the metric.
The official Power BI refresh documentation distinguishes refresh types and describes behavior by storage and connection mode. It supports treating refresh as more than one operation. A custom dashboard still needs states based on its own interfaces, caches and rendering path; Power BI schedules should not become an untested promise for another system.
Set freshness expectations by module
Daily closed revenue does not need the same freshness window as an equipment status. An event-based source cannot automatically be called disconnected simply because no new event occurred. For each module, record its expected schedule, permitted staleness, meaning of an empty response and responsible owner. Distinguish “nothing changed” from “the source did not respond.” Agree actual thresholds from the business context rather than applying one arbitrary number everywhere.
Also test overlapping requests. If an earlier request finishes after a newer one, it should not silently replace the newer batch. After returning to a page or recovering connectivity, inspect the retained data state before fetching a replacement. Do not reset every visible timestamp to the current time while leaving the old values in place.
Accept a deliberately asynchronous screen
Keep one source healthy, make another time out, and return an empty record set from a third. Observe each card and every combined metric. Then reverse response order, alter the client clock and restore connectivity. Confirm that cutoff labels change with their values. Retain interface responses, batch identifiers and screenshots; recording a loading spinner alone does not prove freshness.
Industrial Real-Time Data Integration and Acceptance: PLC, SCADA, MES, and IoT addresses industrial sampling and transport. This article focuses on reading mixed-age data on one screen; terminal recovery is covered in Recovering an Unattended Dashboard After a Connection Failure. When defining data visualization development services, include the module-state table and cross-source update conditions so that responsibility for the screen's actual time basis is settled before launch.