Checkout page loads blank after a deploy
The homepage works and uptime says everything is green, but the checkout or payment page renders blank, half-empty, or stuck on a spinner — usually starting right after a deploy.
- Lovable
- Bolt
- Bubble
- Any stack
- Checkout & payments
Root cause, in plain English
The server is fine; the page dies in the browser, where uptime checks never look. After a deploy, the usual killers are a JavaScript error during checkout render — Stripe.js failing to initialize with a missing or wrong publishable key — an environment variable absent from the new bundle, or visitors holding a cached old index.html that requests hashed asset files the new deploy deleted, so the page's code never loads at all.
How to fix it
Open the live checkout URL in a private window with devtools open. The console error tells you which case you're in: a 404 on a .js chunk means stale-cache/deleted-assets; an initialization error names the misconfigured library.
For chunk 404s: redeploy with cache invalidation on index.html (HTML should be no-cache; hashed assets can cache forever), and consider keeping the previous build's assets available during the transition.
For payment-library errors: verify the publishable key and price/product IDs exist in the deployed environment's variables — not just in your local .env — then rebuild and redeploy.
Click through a real test purchase end-to-end after the fix; a checkout that renders can still fail at confirm time.
Add an error boundary or fallback UI around the checkout component so a future script failure degrades to a visible error instead of a blank page.
Go deeper: read the full guide · copy the open-source health-check recipe.
How Nightlamp detects this automatically
- Browser journey
- Visual snapshot
- Keyword check
A browser_journey loads the checkout in a real browser and asserts the payment form actually renders — the only way to catch failures that happen after the 200 response. A visual_snapshot diffs the rendered page against the last known-good render and flags a blank or broken layout, and an http_keyword check verifies key checkout copy is present in the response.
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 my uptime monitor say everything is fine?
- Plain uptime checks request a URL and check the status code. A blank checkout still returns 200 with valid HTML — the failure happens when the browser executes JavaScript. Only a real-browser check (or a customer) sees it.
- Why does it work for me but customers see a blank page?
- You likely have a fresh cache and an ad-blocker-free profile. Customers may hold a cached index.html pointing at deleted assets, or run extensions that block payment scripts. Test in a private window and with a popular ad blocker enabled.
- How do I stop deploys from breaking cached visitors?
- Serve HTML with no-cache headers so browsers always fetch the current index.html, give hashed assets long cache lifetimes, and avoid deleting the previous deploy's assets immediately — visitors mid-session still reference them.
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.