Does our reporting actually need to be real time?
Only if someone will act inside the refresh window. Dispatch and call handling justify minutes. Marketing spend justifies daily. Revenue and margin rarely justify anything faster than daily, because the underlying records are not final anyway. Refreshing faster than your data matures produces a number that is guaranteed to change, which trains people to distrust the report.
Match freshness to decision latency
For each metric, ask how quickly someone could plausibly act on it and how long the action takes to have an effect. A dispatcher can reassign a job in minutes. A marketing manager can shift budget in a day. An owner reconsidering staffing works in weeks. The refresh interval should sit just inside the fastest useful response, not below it.
Anything refreshed faster than that adds cost and noise without adding decisions. It also creates a subtle problem: people start watching intraday wiggles and reacting to variation that would have disappeared on its own.
There is also a psychological cost. A number that updates constantly invites constant checking, and constant checking converts normal variation into perceived events. Slower refresh on a slow-moving metric is a feature, not a limitation.
The costs that show up later
- Rate limits. Operational systems and ad platforms throttle. Aggressive polling gets you deprioritized or blocked, usually during your busiest hour.
- Incomplete records. Mid-flight jobs have no invoice and calls in progress have no outcome. Frequent refresh guarantees you are reading partial rows.
- Partial-day comparisons. Today at 10am against yesterday's full day is a comparison nobody means to make, and dashboards make it by default.
- Alert noise. Higher frequency means more chances to cross a threshold, which is why fast dashboards and untuned alerts fail together.
Freshness is a property you display, not one you assume
Every panel should carry an as-of timestamp per source, because users assume everything on a screen is current. When one feed is delayed and the rest are not, a rollup silently understates and nobody knows.
Showing source-level freshness also shortens incident response. The first question after a surprising number becomes when was this last updated rather than what happened to the business.
Pair the timestamp with an explicit stale state. When a source misses its expected update window, the panel should say so rather than silently displaying the last good value, which is indistinguishable from a real decline.
The pattern most operators land on
A short list of event-triggered conditions that genuinely need immediate attention, delivered as interrupts, and everything else reconciled on a daily cycle and delivered as a written summary. Two mechanisms, two purposes, and neither one pretending to be the other.
That split is the practical shape of operational AI: events drive action, and daily briefs drive understanding. Trying to make a single always-on dashboard do both is what produces screens nobody opens.
Topics: data freshness · real time · sync · architecture
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.