A real-time dashboard needs a defined freshness expectation. For some decisions, a five-minute delay is acceptable. For live dispatch, a stale vehicle position can mislead an operator. The word real-time should therefore describe measured behaviour, not merely an animated interface.
Define the interval between the business event and a usable display. Include source capture, transmission, processing and rendering. A fast browser update does not help if the source feed stopped half an hour earlier.
Start with the decision
For a hypothetical warehouse control screen, staff may need to know whether a picking queue is growing now. A monthly capacity review does not need the same update frequency. Different views can share data while using different freshness policies.
Ask what action becomes wrong when the data is delayed. This determines whether the system should warn, show the last known state or prevent an automated action.
Display time honestly
Show the timestamp that matters to the user. A dashboard refreshed at 10:15 may still contain a vehicle event from 10:00. Keep event time and display refresh distinguishable.
When delayed events arrive, label them appropriately. Operators should not interpret an old alert as a new incident simply because it appeared on the screen now. Define how historical corrections affect totals and charts.
Choose an update method
| Method | Useful fit | Limitation to examine |
|---|---|---|
| Scheduled refresh | Periodic reports | May be too slow for operational intervention |
| Browser polling | Moderate update needs | Repeated requests and stale intervals |
| Server-sent events | One-way event delivery | Reconnection and missed-event recovery |
| WebSocket | Interactive bidirectional updates | Connection lifecycle and flow control |
A persistent connection does not create reliable history. The application still needs identifiers, reconnect behaviour and a way to recover missed updates.
Control load and information volume
Sending every raw event to every browser can overwhelm both the system and the reader. Aggregate or filter where the decision allows it. Choose sampling and update frequency based on what operators can interpret.
Protect permissions on live channels as carefully as ordinary API requests. A user removed from a role should not continue receiving private events through an old connection indefinitely.
Plan for disconnects
Test a browser sleeping, a network switch and a server restart. On reconnect, determine whether the client needs a fresh snapshot, events since a checkpoint or both.
Avoid showing a green connected badge while the source itself is stale. Connection health, source freshness and processing health are separate signals. A useful degraded state explains what remains known and what needs manual checking.
Evaluate the complete path
Measure latency distribution under representative event volume and concurrent users. Inspect slower cases rather than only an average. Include database writes, queues and event fan-out in the test.
Also test the human workflow: can an operator identify a stale item and choose the correct recovery action? A visually smooth stream can still conceal missing data.
A sound real-time design begins with an operational freshness contract, then selects the simplest architecture that meets it. Faster updates are valuable when they support a timely decision and remain understandable during failure, not merely when charts move continuously.
Primary references
Related reading
Explore our data analytics dashboards to discuss the requirements and evidence for a suitable first release.