How to Auto-Refresh a Shared Dashboard

October 5, 20267 min readDashboards, Teams

To auto-refresh a shared dashboard on SnapHost, open the site's Advanced settings and switch on Auto-refresh on update. From then on, anyone who has the dashboard open is moved to the new version when you publish one, without pressing anything. The setting is off by default and it is free on every plan.

That is the whole answer for the setting. The rest of this post is what an open page does while it waits, what changes when you turn the setting on, why the default is off, what a screen on the office wall needs beyond the toggle, and what auto-refresh does not do for you.

How to auto-refresh a shared dashboard

There are three ways to turn it on, and they all set the same thing on the same site.

In the dashboard. Open the site, go to its Advanced settings, and switch on Auto-refresh on update. It sits next to deep-link routing.
From your AI. If ChatGPT, Claude or Cursor is connected to SnapHost, tell it to turn auto-refresh on for the site. It makes one call, set_render_options with auto_refresh, and reports back.
From the API. The same field on the site's render options, for anyone who scripts their publishing.

Connecting an AI is on every plan, Free included, so the second route is not a Pro thing. Changing the setting changes nothing else about the site: its link, its allowlist, its password and its expiry all stay as they were.

What an open page does while it waits

A published page on SnapHost carries a small check. While the tab is visible, it asks the server every five seconds whether the site has a newer version. When the tab is in the background it asks every thirty seconds, and when you come back to it, it asks again within a second.

The question goes to an endpoint that reads no cookies and serves no content. It answers with a version signal and nothing more, so an open tab asking over and over does not cost the site anything in terms of access, and a viewer whose sign-in has lapsed is not quietly handed the page by the poll.

With auto-refresh off, which is the default, a change in that signal shows the reader a small pill at the bottom of the page: A new version is available, with a Refresh button and a dismiss. Nothing moves until they choose. Dismiss hides that one version only. If you publish again later, the pill comes back, so nobody is left on stale content without being told.

If the check cannot reach the server (a laptop lid closed, a hotel connection), it backs off, up to a minute between tries, and picks up again when the connection returns.

What changes when you turn it on

With the setting on, the same check gets a different answer: the page reloads itself instead of asking. Three details are worth knowing.

Once per version. The tab remembers which version it last reloaded for. It does not reload again until you publish something new, so a screen does not sit there reloading every five seconds.
The reload goes through the front door. A reload is a fresh request, and the server checks the viewer again before serving the new bytes. On a private dashboard, someone you removed from the allowlist is refused on that reload rather than carried along to the new version.
Each tab decides for itself. Two people with the dashboard open both reload; one person with two tabs open sees both reload. There is no shared state between them.

If something is wrong on our side and the version a page was rendered with never matches what the poll reports, the page falls back to the prompt rather than looping. You would see the pill where you expected a silent reload, which is the right failure.

Why the default is off

The setting is described in the product as suited to dashboards and status pages, and that is the honest boundary. A reload moves the page under whoever is reading it. For a dashboard, where the reader is looking at numbers that are supposed to change, that is the point. For a forty-page report, it throws the reader back to the top mid-paragraph, and for a page with a form on it, it drops whatever was half typed into a field.

So the default protects the reader, and you opt in for the pages where the reader wants it. A long document, a proposal, a deck someone is presenting from: leave it off and let the prompt do its job. A set of tiles on a screen that nobody scrolls: turn it on.

The toggle does not make the numbers fresh

This is the part people get backwards. Auto-refresh moves open screens to a new version. It does not create one. Something still has to rebuild the page with new numbers and publish it, and the toggle only decides what happens to the people already looking.

The simple pattern is what the design guide calls the republish model: a routine (your AI, a script, you on a Monday morning) rebuilds the page and updates the site in place. The link does not change, so the screen on the wall and the tab someone left open both reload into the new version. Your AI can do the whole loop over the SnapHost connector: build the page, publish it, and keep publishing it as the numbers move. What you can publish covers the formats, and a dashboard can be a plain HTML page, a spreadsheet, or a single React component your AI hands you.

There is a second pattern for numbers that move within the hour, where the page itself reads values from the site's data layer every half minute instead of being republished. That is a Pro feature, and the design guide steers you to the republish model for a private dashboard anyway: a private page's access to its data lasts a day and renews when the viewer reloads, which a republish with auto-refresh does on its own and a page that only polls does not. Pick the republish model unless the numbers really do change that often. It has fewer parts to break.

Keeping the history while the page keeps changing

A dashboard that republishes itself hourly is also a dashboard that will, at some point, publish a wrong number. On Pro, each update is saved as a version, the most recent ones are kept, and you can roll back to any of them while the link stays the same. A rollback is saved as a version too, so you can move forward again. How to roll back a published web page walks through it. With auto-refresh on, the rollback reaches the open screens the same way a publish does.

Free has no version history. The site updates in place and the previous version is gone, which is fine for a dashboard you can rebuild from its source and less fine for one you cannot.

A screen on the wall

The case that sells this setting is the screen by the kitchen: a dashboard opened once and left running for weeks. Two things matter there beyond the toggle.

First, if the dashboard is private, the screen signed in once by verifying an email, and that sign-in is a sliding window: it is extended on each authorized view and lapses after fourteen days of inactivity, inside a longer ceiling of about ninety days. A screen that reloads on every publish is never inactive, so one sign-in lasts as long as the numbers keep moving. A screen on a dashboard nobody republishes for three weeks will find itself at the verification page instead.

Second, put a clock and a last-updated time on the page itself. Auto-refresh cannot tell anyone that the routine feeding the page stopped running. A dashboard that reads "last updated Tuesday 09:00" under a clock that says Thursday is saying something useful. A dashboard with neither looks exactly the same alive as frozen.

Who can see it

Auto-refresh does nothing to who can open the page, so set that first. On Free, a new site is public by default, you can have three sites at a time at sites.snaphost.ai with a small mark in the corner, and each one can instead be private to up to three named people. For a dashboard that goes to a co-founder and a manager, that is enough. On Pro, a new site is private by default, the allowlist has no cap, a whole company can come in by its domain, and a password or an end date can sit on top. Pro is 19 euros a month for each member who can publish, and viewers are free. Pricing has the current lines.

Private means each viewer verifies their email before the page loads, and the allowlist is checked live on each view rather than once at sign-in. Sharing and access control covers the rest, and how to host a private dashboard online is the longer version of this section.

What auto-refresh will not do

It is worth having these in front of you before you rely on it.

It is not instant. A visible tab notices within about five seconds of a publish, a background tab within about thirty.
It is a full reload. Scroll position, a filter someone picked, a field someone was typing in: gone, unless the page itself saves them.
It only reaches open tabs. Someone who closed the dashboard on Monday sees the new version when they open it, and not before. If they need to know, tell them.
It does not refresh the numbers. See above. If nothing republishes, nothing changes, and the toggle will not help.
It is per site. Turning it on for one dashboard does not touch your other sites.

None of these are reasons to leave it off for a dashboard. They are reasons to leave it off for a report, and to put a last-updated stamp on the dashboard.