For small product teams
The PR was green. Production still broke.
A CI, previews, pull requests, a probe already in place — and a deploy that passes every check before removing the payment button. PostShip checks the preview before the merge, production after, and remembers what broke.
What happens, with nothing
Tests pass, the page doesn't work
A component rendered client-side, an environment variable missing in prod, a third-party script that changed: none of that fails a CI.
The domain still serves the old build
The deploy is green, the CDN cache or the alias didn't follow.
Who broke what, when?
Three deploys in the afternoon, an incident at 5 pm.
What PostShip does for you
The preview checked before the merge
Every Vercel, Netlify or Cloudflare preview goes through the same checks as production.
How it worksProduction actually serves this deploy
After every release, PostShip compares what the domain serves with the deploy URL, and tells you if the CDN, the alias or the DNS are lagging.
How it worksWhat changed, and the probable cause
Every deploy carries what it broke or restored, the before and after image, and the probable cause of an incident — Vercel, Stripe or you.
How it worksProject state in Cursor or Claude Code
An MCP server, a read API and exports: incidents and deploys where the team already works.
How it works
What we're often asked
We already have end-to-end tests.
They run before the deploy, on an environment of their own. PostShip looks at real production, afterwards, from the outside — with the real CDN, the real DNS, the real third-party scripts. It's the gap between “tests pass” and “it works”.
Does it block our deploys?
Never the release. The GitHub Check can hold back a merge if you require it; by default it informs. Automatic rollback is an option, off by default.
We're two, not twenty.
Pro is enough for two if a single account manages the projects. Collaborators per project — and the Check's minimum score — are on Team.