Users still see the old version after a successful deploy
The deploy succeeded and looks right in a private window, while other people still see yesterday's app. Some report a blank screen or missing styling instead, and a hard refresh fixes it for whoever tries it.
- Any stack
- Webflow
- Lovable
- Bolt
- Replit
- Checkout & payments
- Forms & leads
Root cause, in plain English
The HTML document names the exact asset files the app should load. When a cache keeps serving an old document after a deploy, it points at filenames that the new build replaced, so the browser requests scripts that no longer exist. That is why the result is not simply an old version but a broken hybrid: stale markup asking for assets that are gone.
How to fix it
Confirm what visitors actually receive by requesting the page without a cache and reading which asset filenames the HTML references, rather than trusting your own browser.
Cache the HTML document for a short time or not at all. It is the index of everything else, so it must be allowed to change immediately.
Cache the built assets aggressively instead — their filenames already change with their contents, so a long lifetime there is safe and is what makes the site fast.
Invalidate the CDN for the document paths as part of the deploy, not as a manual step someone remembers after a complaint.
Handle the failure in the app: when a required asset fails to load, prompt for a reload rather than leaving a blank page.
How Nightlamp detects this automatically
- Keyword check
- Visual snapshot
- Browser journey
An http_keyword check asserts a string that only the current release contains, which turns a stale document into a failed check within minutes of a deploy. A visual_snapshot catches the specific look of a page whose styling never loaded, and a browser_journey fails outright when a missing script leaves the page inert — the case a status-code monitor scores as a healthy 200.
Catch this before your customers do
Nightlamp runs these checks continuously against your live app and sends a plain-English diagnosis — not a wall of logs — the moment this pattern shows up.
Related patterns
Frequently asked questions
- Why does a hard refresh fix it?
- A hard refresh bypasses the local cache and fetches the current document, which names the assets that actually exist. It fixes it for that one person on that one device, which is precisely why it is a poor way to find out how widespread the problem is.
- Why is the page blank rather than just old?
- Because the stale document asks for asset files the new build replaced. Those requests fail, the app never starts, and you get an empty page rather than the previous version. A purely old page means only the document is stale; a blank one means the two halves disagree.
- Isn't caching the HTML what makes the site fast?
- The assets are where the weight is, and those can be cached almost indefinitely because their names change whenever their contents do. Keeping the small document fresh costs very little and is what lets everything else be cached hard.
Newsletter
Get new incident patterns as we publish them
One email when new failure patterns, fixes, and monitoring recipes for no-code and AI-built apps land. No fluff, unsubscribe any time.
Double opt-in. One-click unsubscribe. No spam, ever.