Short answer
StackBlitz does not publish an exact cache TTL for preview assets, does not document any difference between free and paid tiers, and does not document a programmatic cache-purge API or rate limits for it. The Refresh Preview button triggers a rebuild and a fresh fetch from the CDN, but it does not clear browser-level caches, so stale content can still appear if a service worker or the browser's HTTP cache holds the old iframe content. If you need to see a change immediately, the reliable combination is: Refresh Preview, then a hard reload (Ctrl+Shift+R / Cmd+Shift+R) or a cache-busting query parameter.
Confirmed vs. likely
It is worth separating what is confirmed from what is inference, because the question asks for numbers the platform has not committed to:
- Confirmed: StackBlitz serves preview assets through a CDN and states that assets are cached for a short period. No exact TTL is published in the documentation.
- Confirmed: Refresh Preview forces a rebuild and re-fetch of assets. It is a build/CDN-level refresh, not a browser cache clear.
- Not documented: Any TTL difference between free and paid tiers, and any API or rate limit for programmatic purging.
- Likely but unverified: Community observations suggest a TTL on the order of a few minutes (roughly 5 minutes is commonly reported for free-tier projects, with some reports of longer windows on paid tiers). Treat these figures as anecdotal, not contractual — they can change without notice.
Why stale content can survive Refresh Preview
Even when the button successfully busts the CDN cache, two browser-side layers can still serve the old version:
- HTTP cache: the preview iframe's documents and assets may be cached by the browser with their own freshness lifetimes.
- Service worker: if the previewed app registers a service worker, it can intercept requests and serve cached responses regardless of what the CDN now holds.
A hard reload bypasses the HTTP cache. For a service worker, you may need to unregister it (DevTools → Application → Service Workers → Unregister) or open the preview in a private window.
Practical workflow
For day-to-day editing, do not design around a specific TTL. Instead:
- Edit the file and click Refresh Preview.
- If the change does not appear, hard-reload the preview pane.
- If it still does not appear, check for a service worker in the previewed app and unregister it.
- For scripted checks, append a unique query string (for example
?v=1697260000) to the preview URL so each fetch is treated as a new resource.
Programmatic purging
There is no documented purge endpoint, so there are no documented limits either. Manually triggering refreshes at a human pace is fine; hammering refreshes from a script risks temporary throttling and provides no guarantee of fresher output than the normal rebuild path. If you need deterministic freshness in automation, cache-busting query parameters are the safer tool than repeated purge attempts.
Verifying the TTL yourself
Because the TTL is unpublished, the only trustworthy number is the one you measure:
- Edit a file, note the time, and watch the preview without touching Refresh Preview.
- Record how long until the change appears on its own — that approximates the effective TTL for your account.
- Repeat after clicking Refresh Preview to confirm the button shortens the wait, and after a hard reload to confirm the browser cache was the remaining layer.
If your measured TTL matters for a team workflow, re-check it periodically, since an unpublished value can change at any time.
stackblitz