A dashboard should refresh as often as the decisions made from it require, not simply as fast as possible
Aliases: refresh rate · freshness requirement
What it is
A dashboard's refresh frequency is not "the more real-time the better"—it should be driven by what decisions users make on this data and how often. An on-call operator may need to decide whether to scale every minute, making second-level refresh valuable; a finance user reads a report monthly, where daily refresh is already more than enough and hourly refresh merely wastes attention and compute. When refresh frequency mismatches decision frequency, either the data lags the decision need (the user sees stale state) or the data jumps faster than the user can absorb (extending into the same group's disruption problem).
Why it happens
Both ends of the mismatch carry a cost. When refresh is too slow, users decide on stale data—the price of delay depends on the decision window: one minute of lag can cause a wrong trade, while one day of lag is irrelevant for monthly planning. The key variable is the ratio of decision frequency to data change frequency: when data changes faster than decisions, the user needs only "new enough to answer the current question"; when data changes slower than decisions, even the fastest refresh just repeats the same data. When refresh is too fast, the cost shifts to the user: reading is interrupted (see the same group's jumping problem), backend query pressure grows, and users misjudge data reliability—frequent tiny number changes make people suspect pipeline instability, eroding trust rather than building it. A technical constraint also applies: refresh frequency is bounded by pipeline latency; if upstream data arrives in 5-minute batches, a 1-second front-end refresh just re-requests the same batch.
Where it stops holding
Decision frequency is a property of the situation, not the person: the same user needs second-level data during incident response and hourly data for routine checks—a dashboard should let users adjust refresh frequency rather than hard-coding one value. For push-style alerting (notify the user when a threshold trips), pull-style dashboards can lower refresh substantially, since emergencies already arrive through another channel. Shared dashboards face a hidden constraint too: a refresh rate tuned for high-frequency decision-makers is noise for low-frequency users; configure by role, not globally.
Applying it
- Define each dashboard's target decision scenario (how often, what decision) and set refresh frequency to 1/3–1/2 of that interval.
- Offer a user-adjustable refresh option (off / 30 seconds / 5 minutes) with a default matched to the dashboard's primary use.
- When pipeline latency is known, cap front-end refresh at or below that latency to avoid re-requesting the same batch.
- Verification: measure the proportion of auto-refreshes where the user actually noticed a data change; below 20%, refresh frequency exceeds the decision need—lower it.