Why operating dashboards should not refresh continuously

Refresh should follow real demand

Continuous scanning spends database connections and background work on dashboards nobody is viewing. A better policy separates event-driven monitoring, on-open operating dashboards, and batch historical review.

Recent AskTable code, which underpins BI0 analysis workflows, changed dashboard and table refresh to lazy triggers and removed periodic cursor scanning.

The hidden cost of polling

As dashboards grow, many scheduled checks conclude that no update is needed. They still consume queues, caches, and connection pools and can create tenant-wide spikes.

A one-minute dashboard refresh cannot make an upstream ERP feed that updates daily become real time. Start with the business freshness requirement.

Protection around demand-driven refresh

Deduplicate concurrent requests, expose pending and result timestamps, preserve the last valid result on failure, and enforce source-specific query timeouts. Public or shared dashboards also need trigger permissions and rate limits.

Demand-driven does not mean unlimited. Idempotent task keys, short caches, and tenant quotas protect shared systems.

How to validate the mechanism

Test unused, popular, and slow dashboards. Verify that idle content creates no work, concurrent views share a refresh, timeouts preserve old results, and recovery updates the correct version.

Track waiting time, duplicate jobs, recovery time, and resource use. Event-driven architectures remain more suitable for transaction risk or equipment alarms.

Evidence boundary

This article is based on the 2026-07-25 lazy-refresh implementation and tests in the read-only AskTable repository. Exact policies depend on the deployed product version.