Probable cause
What changed right before, said in one sentence
An alert that says “/checkout failing” leaves you investigating. An alert that says “/checkout failing, three minutes after deploy a1b2c3d removed Stripe.js” leaves you fixing.
“I spent an hour searching before I saw my colleague's commit.”
The longest part of an incident isn't fixing: it's understanding.
- sources checked: deploy, DNS, host, payments
- 4
- sentence in the alert
- 1
- the changed files, when it's a deploy
- diff
- accusations: a lead, not a verdict
- 0
sources checked: deploy, DNS, host, payments
sentence in the alert
the changed files, when it's a deploy
accusations: a lead, not a verdict
How it works
01The latest deploy, and what it changed
When the site is connected to GitHub, PostShip knows the files touched by the deploy that precedes the failure.
02DNS and the certificate
An A record that changes, a certificate that expires: PostShip records both on every pass and can say whether they moved between the last green pass and the first red one.
03Your host and your payment provider
The status pages of Vercel, Netlify, Cloudflare and Stripe are read at the time of the incident.
04A lead, dropped if it doesn't hold
The probable cause is the closest in time and the most tied to the broken page.
What we're often asked
What if the cause isn't in the list?
Then the alert doesn't make one up. It says what changed and what didn't, which is still a good way to start. The project's log keeps the full timeline for afterwards.
Do you read my code?
Only the list of files changed by a deploy, through the GitHub App you install — not their content. The diff shown in the alert is the one GitHub already shows your collaborators.
Does it replace an observability tool?
No: it answers the first question, not all of them. For a full trace, Sentry or your host remain the natural next step — and PostShip's alert sends you to the right place there.
Paste your site's URL. PostShip checks it in front of you, no account and no card.