Incidents

An incident is a failing URL. It opens without you, the moment PostShip agrees to write to you, and closes without you, at the return to green. In between, the only human decision is to tell it: one sentence, published on the status page and sent to the subscribers. It isn't an on-call tool, no rotation or SMS: it's what a status page must be able to show, and the only step in the chain that needs someone.

What PostShip does

Opening

An incident is born at the N-th failure confirmation, N being the “Confirmation before alert” of Rules (1 by default). It's the same instant as the alert, and that's intended: there is an incident when there is something to write to someone about. It's born even if the alert itself is then swallowed by deduplication, quiet hours or a maintenance: an outage whose alert is held back is still an outage.

It carries, from its opening, a summary pre-filled with the alert's sentence: “/checkout answers 503.”, “The price no longer appears on /pricing.” — the path, never the whole URL, because this text can end up on the status page. A single open incident per URL: 2 concurrent runs can't create 2.

Closing

The URL's return to green switches the incident to “Resolved” and sets its recovery time, whether a recovery alert goes out or not. The summary isn't rewritten: what was said during the outage stays what was said.

Publishing

An incident starts unpublished. The outage is real, the decision to announce it is the owner's. Publishing sends the sentence to the status page, in the history it shows, and by email to the page's subscribers (“Ongoing incident”, or “Incident resolved” if the incident was already closed). Updating the sentence afterwards doesn't notify the subscribers twice.

The Incidents page

Project → Incidents, top to bottom.

• The silence bar: “Mute 1 h / 4 h / 24 h” and “Resume alerts”. Mutes all the project's alerts, all channels together; monitoring continues.
• Ongoing: one card per failing URL — the type, the cause in a sentence, since when, who is on it (or “nobody is on it yet”); a payment page is marked. The card opens the incident room.
• Last 30 days: incidents, median recovery, the longest, median time to acknowledge, share acknowledged — each figure compared with the 30 days before.
• Day by day: one bar per day over the period (calm, incident, incident on a payment page). Clicking a day lists its incidents.
• History: every resolved incident as a card — duration, published or not, who took it on, the probable cause. Filters: all, ongoing, resolved, published, payment pages; period 7, 30 or 90 days. 20 cards, then “Show all N incidents”.

The incident room

For every open or recent incident:

1. The state: “Investigating”, “Identified”, “Resolved”, followed by “· unpublished” as long as it isn't; “opened 12 min ago”, “recovered 3 min ago”.
2. “I'm on it” or “Taken by marie 12 min ago”: see Taking charge.
3. “What your customers will read”: the sentence, 140 characters at most. A status page is read in 10 seconds on a phone; what doesn't fit is an article you'll never write during an outage. Then “Publish”, which becomes “Update”.
4. Once published: the buttons to the other states (“Identified”, “Resolved”, “Investigating”) and “Remove from the page”.
5. The “Probable cause” link to the timeline and the post-mortem: see Probable cause.

What triggers an alert

The opening of an incident and the failure alert are the same event, subject to the same rules: see Email, Discord, Slack. The state change or the publication send nothing on your channels; the publication sends to the status page's subscribers. The escalation, if set, sends the incident again to the whole team when nobody took charge of it in time.

Limits and plans

See the plans and Data and retention.

Troubleshooting

Why doesn't my incident appear on the status page?

It isn't published. Write the sentence and click “Publish”. The page only shows published incidents, and only over your plan's history window.

Why does the journal show an alert when I received nothing?

The journal records what was sent by PostShip. If the email didn't arrive, look at your spam and the “A URL fails” checkbox in Account → Notifications. If a chat channel is missing from the channels column, its sending failed (webhook deleted, for instance): reconnect it from Integrations.

Probable cause

How PostShip puts the signals side by side around an outage and draws ranked hypotheses from them.

When a URL goes down, PostShip knows many other things at the same moment: a deploy just went out, Vercel is in incident, the DNS changed, the other pages went down too. The probable cause puts these signals on a timeline and draws hypotheses from them, ranked. It's temporal correlation, nothing more: a deploy 3 minutes before a 503 is a suspect, not a culprit. The sentences say “probable”, never “certain”, and say why.

What PostShip looks at

The window is 2 hours before the start of the incident and 30 minutes after its end (or after its start, as long as it isn't resolved, so the page doesn't change on every read). The signals read, each dated:

A read that fails doesn't bring down the others: a missing signal is better than an empty page.

The scoring rules

Scores add up per cause, never across causes. Under 25, the hypothesis is noise and isn't shown. From 35, medium confidence; from 60, strong confidence. If everything is under the threshold, a single “Unknown cause” hypothesis is returned, with the same clarity: “No signal precedes the outage: no deploy, no DNS change, no provider in incident. Look at the server logs around 14:03.”

At equal score, the order above breaks the tie: the most decisive first. Each kept hypothesis comes with a full sentence (“A deploy (a1b2c3d) went out 3 min before the outage.”) and one line of evidence per signal used, so you can dispute.

The timeline

The start, the window's signals, the end, sorted by date, with their relative position: “3 min before”, “at the time of the outage” (within a minute), “12 min after”. In the post-mortem, times are in UTC: those of your server's logs.

Where to read it

• Project → Incidents → “Probable cause” on the incident room: the probable cause, the other hypotheses, the timeline, then the “Post-mortem” card.
• The post-mortem is the same content in Markdown: duration, impact, timeline, probable cause and evidence, “What PostShip didn't see”, taking charge. The button copies the text; the “Share through a link” box creates an unlisted /pm/<token> address, which you can withdraw. See Post-mortem.

Limits and plans

Computed for every incident, on all plans. Its richness depends on what the project observes: without a deploy webhook, no deploy signal; without multi-region (Pro Plus), no regional verdict; without anomalies (Pro), no saturation. See the plans.

Troubleshooting

Why “Unknown cause” when I deployed?

The deploy isn't in the 2-hour window, or it wasn't recorded (webhook missing, or a preview deploy rather than production). The timeline lists everything that was seen: if the deploy isn't there, PostShip didn't know about it.

Why is the deploy cited when the cause is elsewhere?

It's a prior: a deploy within the half hour makes +60 by construction. Read the evidence and the other hypotheses; if the other URLs were responding, the score was already lowered by 10, and the sentence says so.

Providers

The 12 status pages PostShip follows, how it guesses which ones concern you, and what that changes in the alert.

When Vercel or Cloudflare goes down, you receive “your checkout answers 502” and search on your side for an hour. The information you're missing is public: the provider's status page already says it. PostShip reads it and puts it next to the alert, “It may not be you”, and on the project's Overview. You have nothing to declare: providers are inferred from the scripts your pages load.

What PostShip follows

12 providers, all read through the same API (Statuspage, /api/v2/status.json), in the order they're shown: hosts and network first, because that's where an outage explains a 502.

A provider whose status page doesn't speak that dialect isn't in the list: better to say nothing than to misread. That's the case of Stripe, whose page is home-made. cdnjs.cloudflare.com counts as Cloudflare, on purpose: if Cloudflare goes down, the CDN goes down with it, and the site too.

The states

Statuspage's vocabulary: none (operational), minor, major, critical, maintenance. Only minor, major and critical count as “in incident”: an announced maintenance doesn't excuse a 502, and “none” has nothing to say.

How PostShip knows which providers are yours

Third-party origins are collected on your pages at the time of a production deploy (the last 3 recorded). A site that loads va.vercel-scripts.com is on Vercel, whether it said so or not. Only the host is compared, never the whole URL: an unknown origin matches nothing, and better one provider fewer than a false “Vercel reports an incident” on a site that isn't there.

Without a recorded deploy, the list is empty, not wrong: see Deploy webhooks and Detection without webhook.

Freshness

The 12 pages are re-read by PostShip's run when the most recent read is more than 10 minutes old, 4 pages at a time, 4 seconds per page at most. The cache is shared by all projects: Vercel has only one state, whatever the project looking at it. On failure (network, timeout, non-200 response, unreadable JSON), the line is not touched: the old state stays, with its old date. A status page that doesn't respond doesn't mean “all is well”; writing “operational” in its place would be lying with a fresh date.

What it changes

In the alert

When something goes down, the alert reads the state of the project's providers. If one of them is in incident, a sentence is slipped right under the recap, on every channel:

• a single one: “It may not be you: Vercel reports an incident (Elevated errors on deployments).” — the description comes from the provider's page;
• several: “It may not be you: Vercel, Cloudflare and Supabase report an incident.” — the names only, 3 descriptions end to end don't read.

No provider in incident: nothing is added. A read error never holds the alert back. See Email, Discord, Slack.

On the Overview

Project → Overview, “Your providers” box: one name per detected provider, a dot (green, blue in maintenance, red in incident), a link to its status page, and “checked 4 min ago”. In incident, the box turns amber and adds: “An outage at Vercel can explain a failure of your checks without anything having changed on your side.” Without a detected provider, the box doesn't appear.

In the probable cause

A provider in incident during the window is worth +50 (major or critical), +25 (minor) or +20 (maintenance) to the “Provider incident” hypothesis, with the description as evidence. As there is no history, this signal is only read if the incident is ongoing or ended less than 3 hours ago. See Probable cause.

On the Third parties page

The Third parties page is shelved since 25 Sept. 2026 (it will come back); it showed the site's providers — detected on deployment or declared by hand for those detection cannot see (a service called server-side) — with their current state, their status page, and 30 days of incidents on their side: each state change of their page is recorded at refresh time. The page also lists the API contracts the project monitors.

The “Third party in incident” alert

When one of the project's providers goes into incident (minor, major, critical) on its status page, an alert goes out on your channels — “Vercel is in incident — Elevated errors” — then another when it is restored. On the transition only: not an alert every 10 minutes while the incident lasts. It can be switched off in Alerts → Alert rules.

Limits and plans

The providers' state is read and shown on all plans; the Third parties page, declared providers, the history and the transition alert are Pro Plus. Detection requires recorded deploys, and the deploy webhooks are included in every plan; the fingerprint detection works everywhere. See the plans.

Troubleshooting

Why doesn't Vercel appear when my site is at Vercel?

Your pages load none of the table's origins: a Vercel site without Analytics or Speed Insights, served on its own domain, doesn't give itself away. Detection only reads what the page loads, never the DNS.

Why does the note say “incident” when the provider's page is green?

The cache is up to 10 minutes behind, and a status page that didn't respond keeps its last state. Look at “checked … ago” on the Overview.

Why isn't Stripe followed?

Its status page doesn't serve up-to-date JSON in the Statuspage format. Rather than misreading, PostShip says nothing. The Stripe check looks at your checkout, not their status.