A deploy can break checkout without taking the site down

PostShip replays your critical pages on every release and warns you before your customers notice.

Set up in two minutes
5 URLs free, no card
Data hosted in Europe

What will be checked

Page and assetsThe HTML responds, and so do the JavaScript, CSS and images.
IndexabilityNo noindex left behind by mistake, consistent canonical.
Share cardTitle, description and image present, in the right format.
SitemapReachable, and the URLs it lists respond.
CertificateValid, and the number of days before it expires.
AI visibilityChatGPT, Claude and Perplexity can read you and cite you.

On your own address, live, without creating an account. The result shows up here.

On every deploy

Six checks, one that fails, and the message that goes out

The blind spot

Your uptime probe watches the server. Your customers use the page.

How it happens
A deploy changes the names of the JS files (the hash in app-3f2a.js). A cache or a CDN still serves the old HTML, which points to the old name: the page answers 200, the script behind it answers 404.
What PostShip checks
PostShip reads the HTML, then requests every script, stylesheet and image it references — as a browser would. A single 404 on a required file, and the page fails.
What you receive
Home — 1 asset in 404: /_next/static/chunks/app-3f2a.js
Read the documentation
How it happens
An update removes the payment script tag, or the checkout page changes template. The page stays pretty and empty; the server, for its part, answered 200.
What PostShip checks
The money path requests the pages in order — home, pricing, checkout — and checks on the payment page that js.stripe.com is referenced and that the form (email or password) is there. It stops at the first broken step.
What you receive
Checkout — js.stripe.com missing from the page
Read the documentation
How it happens
Staging carries a noindex so it isn't indexed. One forgotten environment variable, and production inherits it. Nothing breaks on screen; Google removes the pages one by one.
What PostShip checks
On every deploy, PostShip rereads the robots tag, the X-Robots-Tag header and the canonical of every monitored page, and compares them with what they were before.
What you receive
Home — noindex appeared since deploy a1b2c3d
Read the documentation
How it happens
The share image is a file like any other: renamed, moved, or served from a domain that changed, it disappears without anyone seeing — until the next link posted.
What PostShip checks
PostShip reads og:title, og:description and og:image, requests the image, checks that it responds and has an image format, and shows you the card as the networks will see it.
What you receive
Home — og:image returns 404 (/og.png)
Read the documentation
How it happens
The sitemap is generated from the database or the code, and rarely follows the pages you delete. Google reads it, requests pages that no longer exist, and lowers its trust in the rest.
What PostShip checks
PostShip fetches the sitemap, checks that it is well-formed, extracts its URLs and actually requests a sample of ten on every pass.
What you receive
Sitemap — 3 URLs in 404 out of 10 requested
Read the documentation
How it happens
Automatic renewal fails silently — a DNS rule, a quota, a validation that no longer completes. As long as the certificate is valid, all is well. The day it expires, nobody gets in.
What PostShip checks
On every pass, PostShip reads the certificate's expiry date and warns at 30 days, 7 days and 1 day — and watches the certificates issued for your domain, to see a renewal that isn't coming.
What you receive
Certificate — expires in 6 days (18 September)
Read the documentation

Six common failures after a deploy, the answer of an uptime probe and the answer of PostShip. Each row expands.
What breaks	Your probe says	PostShip says
	200 OK	Assets replayed, not just the HTML
How it happens A deploy changes the names of the JS files (the hash in app-3f2a.js). A cache or a CDN still serves the old HTML, which points to the old name: the page answers 200, the script behind it answers 404. What PostShip checks PostShip reads the HTML, then requests every script, stylesheet and image it references — as a browser would. A single 404 on a required file, and the page fails. What you receive Home — 1 asset in 404: /_next/static/chunks/app-3f2a.js Read the documentation
	200 OK	Checkout journey followed to the end
How it happens An update removes the payment script tag, or the checkout page changes template. The page stays pretty and empty; the server, for its part, answered 200. What PostShip checks The money path requests the pages in order — home, pricing, checkout — and checks on the payment page that js.stripe.com is referenced and that the form (email or password) is there. It stops at the first broken step. What you receive Checkout — js.stripe.com missing from the page Read the documentation
	200 OK	Indexability and canonical checked
How it happens Staging carries a noindex so it isn't indexed. One forgotten environment variable, and production inherits it. Nothing breaks on screen; Google removes the pages one by one. What PostShip checks On every deploy, PostShip rereads the robots tag, the X-Robots-Tag header and the canonical of every monitored page, and compares them with what they were before. What you receive Home — noindex appeared since deploy a1b2c3d Read the documentation
	200 OK	Share card checked and displayed
How it happens The share image is a file like any other: renamed, moved, or served from a domain that changed, it disappears without anyone seeing — until the next link posted. What PostShip checks PostShip reads og:title, og:description and og:image, requests the image, checks that it responds and has an image format, and shows you the card as the networks will see it. What you receive Home — og:image returns 404 (/og.png) Read the documentation
	200 OK	Sitemap URLs actually requested
How it happens The sitemap is generated from the database or the code, and rarely follows the pages you delete. Google reads it, requests pages that no longer exist, and lowers its trust in the rest. What PostShip checks PostShip fetches the sitemap, checks that it is well-formed, extracts its URLs and actually requests a sample of ten on every pass. What you receive Sitemap — 3 URLs in 404 out of 10 requested Read the documentation
	200 OK	Expiry watched ahead of time
How it happens Automatic renewal fails silently — a DNS rule, a quota, a validation that no longer completes. As long as the certificate is valid, all is well. The day it expires, nobody gets in. What PostShip checks On every pass, PostShip reads the certificate's expiry date and warns at 30 days, 7 days and 1 day — and watches the certificates issued for your domain, to see a renewal that isn't coming. What you receive Certificate — expires in 6 days (18 September) Read the documentation

Versus UptimeRobot, Oh Dear, Better Stack

Who it's for

Three ways to learn about an outage. Only one is acceptable.

How it works

Four steps, then nothing left to do

Declare your URLs
The domain, then the pages that matter.
Every deploy triggers the checks
Vercel, Netlify, Cloudflare: one click.
Silence while everything passes
One grouped alert when it breaks, nothing otherwise.
Your customers know without writing to you
A status page at your own address.

During the outage

The page your customers open

Public, at your address, kept up to date on its own. From the free plan.

See ours, for real

The proof

What you can verify before believing us

Our status, in public: PostShip monitors itself with PostShip.; The status page
Your data stays in Europe: Hosting and processing in the European Union, never resold.; The policy
Nothing set without your consent: The session cookie, and nothing else until you say yes.; Cookies

Know before your users do, not from the comments

Try Pro for 14 days Or 5 URLs for free

Card charged on day 14, cancel in one click. The free plan never ends. See the plans

A deploy can break checkout without taking the site down

Six checks, one that fails, and the message that goes out

Your uptime probe watches the server. Your customers use the page.

Three ways to learn about an outage. Only one is acceptable.

Four steps, then nothing left to do

Declare your URLs

Every deploy triggers the checks

Silence while everything passes

Your customers know without writing to you

The page your customers open

What you can verify before believing us

Know before your users do, not from the comments