Skip to main content
A refresh re-runs every widget’s pipeline. It calls the source, applies the stored transform, publishes the new rows, and records when that happened. A steady-state refresh makes no model call. The transform was written once, when the widget was built, and re-running it is ordinary computation. So a dashboard refreshing hourly is not burning model spend hourly. The model comes back only when a source changes shape and the transform has to be repaired. Schedules are available on every plan. What they need is funding. A schedule runs on the allowance of whoever it is attributed to and falls back to the workspace pool, and one with neither suspends until there is budget again. See Usage.

​
Setting a schedule

On the dashboard, open Settings → General and use the Schedule card. The grammar is Every [n] [unit].
15 minutes is the floor, on every plan. The scheduler ticks every 15 minutes, so a tighter interval could not run more often. It would only make the setting lie about what it does. Minute values are a preset list for the same reason, since “every 49 minutes” would silently run hourly.

​
Schedules pause when nobody is looking

A schedule auto-pauses after a stretch of days with no visits. Opening the dashboard while signed in switches it back on and queues a catch-up run, which lands on the next 15-minute sweep rather than instantly. You get a brief notice rather than a banner with a button to press, because by the time anyone reads it the schedule is already back on. Two cases worth separating.
  • A signed-in visit revives a paused schedule. Reading the dashboard in the app is what does it.
  • An anonymous share-link view does not. It records the visit, which is enough to keep a running schedule from decaying, but it will not restart a paused one. Otherwise anonymous traffic could put paid refresh work back on the owner’s budget without the owner being involved.
So a dashboard read only through a public link stays alive while it is alive, and once it has lapsed somebody with an account has to open it. This exists so nobody pays to refresh dashboards no one opens. It is housekeeping rather than a restriction.

​
Whose credentials run it

A scheduled refresh runs as the dashboard owner, on the owner’s connections. An editor can set the schedule and rewire widgets, but never lends the dashboard their own data sources. If the owner leaves the workspace, the schedule is disabled and says so rather than retrying against credentials that no longer exist. Reassign ownership from Settings → Sharing → Change owner.

​
Staleness and expiry

Every published set of rows records the date it was fetched. On a share link that surfaces as a “data as of” stamp, so an outside reader can always see how old the numbers are. In the app there is no dashboard-level stamp. Each widget records when its sources last ran, which you can see by expanding it. Published data does not live forever. Rows expire after 28 days, so a dashboard whose schedule lapsed long enough ago is expired rather than quietly stale. What you see then depends on who you are.
  • An anonymous link viewer is told the dashboard has expired, and to contact the owner.
  • A viewer is told how many charts expired, and that an editor needs to refresh.
  • An owner or editor has the expired charts re-fetched as the page loads, on their own allowance.
  • Anyone missing a connection the dashboard depends on is told how many charts need one they do not have.

​
Refreshing by hand

You can refresh a whole dashboard, a single widget, or one stage of a multi-source widget. Manual refreshes draw on your own compute allowance. See Usage. When a refresh fails or gets stuck, you get a notification carrying the error rather than a dashboard that silently shows old numbers. See Notifications.