Why is my checkout page blank but still returns a 200?

Uptime checks only read the status code, not the rendered body. A deploy can leave the route 200ing while the JavaScript that mounts the checkout fails, a CSP rule blocks Stripe.js, or the server returns a "we'll be right back" placeholder. A keyword check that asserts the payment SDK marker is present — and a maintenance string is absent — catches what a status check can't.

Why won't my buy button work after I published or deployed?

The common causes are a changed or removed route, a third-party script blocking render, a CSP/CORS change breaking the payment SDK iframe, or the page now requiring login and redirecting anonymous visitors. Open the page in incognito, check the browser console for blocked-script errors, then compare the route to the last known-good deploy.

Why does the Stripe payment iframe never appear on my checkout page?

Usually a Content-Security-Policy directive is blocking it: script-src and connect-src must allow js.stripe.com and api.stripe.com, and Stripe also needs frame-src (and a worker-src for its blob-based web worker). If those are missing the page renders but the iframe never mounts.

How do I monitor a checkout page so I know before customers do?

Run three checks of increasing fidelity: an http_status heartbeat that the URL exists, an http_keyword check asserting the payment SDK marker is present and a maintenance string is absent, and a browser_journey that clicks the buy button and asserts the payment iframe becomes visible. The browser journey catches the client-side breakage the keyword check misses.

Checkout & buy pages

Your checkout page won’t load? Find what broke before the next buyer bounces.

The page returns 200, so uptime tools call it healthy — but the buy button spins forever, the payment box never loads, or visitors hit a “we’ll be right back” screen. A page that renders and a page that works are two different things, and the gap is where revenue leaks. Here is the fast triage list, and the check that catches a checkout that’s broken behind a green status.

Start 14-day trial Copy the checklist

why it happens

A page that loads is not a page that sells.

Most monitors stop at “did the server answer?” Your checkout can answer 200 while serving a maintenance placeholder, a login wall, or a shell whose payment script was blocked at render. The buyer doesn’t see your status page — they see a dead button and leave. Catching this means asserting the page is the real checkout, then proving the buy flow actually reaches payment.

the checklist

Six ways a checkout page breaks behind a green status

A deploy changed or removed the checkout route

Symptom: The buy link now 404s, or silently redirects somewhere that isn't checkout.

Fix: Compare the live checkout URL against the last-known-good route and your recent deploys; roll back the deploy if the timing lines up.

A blocking third-party script never finishes loading

Symptom: The page renders but the buy button spins forever and the payment box never appears.

Fix: Open the console on the live page; look for a blocked or failed Stripe.js, analytics, or font request, and unblock or defer it so render isn't held hostage.

A CSP or CORS change broke the payment SDK iframe

Symptom: Everything looks fine until checkout, where the embedded payment frame stays blank.

Fix: Allowlist the payment provider's domains (e.g. js.stripe.com) in your script-src / connect-src / frame-src directives after any header or security change.

The page now requires login and redirects anonymous buyers

Symptom: Logged-in testing passes, but real first-time visitors get bounced to a sign-in screen.

Fix: Always test checkout in incognito; if an auth gate crept in, make the buy path reachable without an account.

It returns 200 but the body is a placeholder

Symptom: Status is green, yet the page shows a "we'll be right back" message or an empty shell.

Fix: Assert a known checkout marker is present and a maintenance string is absent; if a maintenance keyword fired, confirm it was intentional before clearing it.

A client-side error breaks the button after render

Symptom: The page paints correctly, but clicking buy does nothing and no payment step opens.

Fix: Reproduce the click in a real browser session, read the console error, and ship the fix; assert the payment iframe becomes visible as your pass condition.

copyable runbook

Paste this into your incident notes

Checkout page triage

[ ] Open the checkout URL in incognito — does the payment box render?
[ ] Confirm the page body contains the payment SDK marker (e.g. js.stripe.com).
[ ] Confirm the body does NOT contain a maintenance/"be right back" string.
[ ] Open the console; look for blocked scripts (CSP), CORS, or failed SDK loads.
[ ] Compare the live route to the last-known-good URL + recent deploys.
[ ] Click the buy button; confirm the payment iframe actually appears.
[ ] If a maintenance keyword fired, confirm it was intentional.
[ ] Roll back the last deploy if it correlates, then re-test the buy flow.

how to catch it automatically

Three checks that walk the buy path, not just ping the URL

Nightlamp layers three probes so a green status can’t hide a dead checkout. An http_status check confirms the URL still exists. An http_keyword check asserts the payment SDK marker is present and a maintenance string is absent — that is what catches “200 but broken.” And a browser_journey check clicks the buy button and asserts the payment iframe actually renders, catching the client-side breakage no status code will ever show.

Checkout route 404s

Missing payment SDK marker

Maintenance placeholder served

Blocked script / CSP errors

Buy button never responds

Payment iframe never mounts

Want a blank checkout caught before the next buyer does?

Start a trial, point Nightlamp at your checkout URL and the buy button, and we will walk the path on a schedule — status, content, and a real click — then page you in plain English with the fix the moment payment stops loading.

Start 14-day trial · no card