Status page

One public page per project, at the address postship.fr/s/your-address. It shows the state of each monitored URL — named by its path, never by its whole URL — and the uptime over the history window your plan keeps. No failure detail, no email address, no access to your dashboard.

What the page shows

• A global state, said by the worst of its components: “All systems operational”, “Degraded performance”, “Outage in progress”. The title is what most people read, it must be true on its own.
• One component per monitored URL — the pages, journeys, forms, API contracts, certificate, sitemap, social card you added. The site checks (security, accessibility, tags, weight, leaks, third-party scripts…) never appear on it: a status page says whether the site responds, not whether it's well made, and a missing HSTS header isn't an outage for your visitors. 3 states: Operational, Degraded, Down. A check in fail is down; a check in error is degraded — it's PostShip that didn't manage to conclude, not the site that answered wrong. A target never run is operational until proven otherwise: “unknown” on a status page worries without informing.
• Uptime, as a percentage to 2 decimals, over the displayed targets only, over the window announced next to the figure.
• One bar per day, for each component family and each component: green from 99% of successful runs that day, amber below, red under 80%, a plain grey line on a day without runs. The bars start when the project was created (at least a week), not before: a site monitored for fifteen days shows fifteen bars, not seventy-five empty days.
• The history, month by month, at /s/your-address/history: each component's uptime day by day and the incidents published that month, since the project was created.
• An announced maintenance, which takes precedence over everything: the site may be red, but someone stands behind this interruption. Upcoming windows over 30 days, with an “Add to my calendar (.ics)” link — see the calendar.
• Published incidents over the kept window, with their state and recovery time.
• “Seen from the world”, the state per continent, for a project probing from several regions.
• A subscription form, from the Pro plan, and the “Powered by PostShip” mention as long as you haven't removed it.

A component's name is the URL's path (/checkout, or “Home” for /); a social card becomes /page (social card); a check that isn't about a page (certificate, sitemap) takes its type's name.

Set it up

Project → Public → Status.

1. Page address: lowercase, digits, hyphens, 3 to 40 characters, never a reserved word (api, app, status, docs…). PostShip suggests one from the project's name.
2. Displayed title (80 characters), empty to keep the project's name.
3. Publish the page. Before, the address answers “not found” to everyone — except you, through “Page preview”, which shows a draft forbidden to robots. “Take down the page” is reversible at any time.
4. Components: each monitored URL has a Hide / Show button. Hiding a component doesn't stop monitoring it: it disappears from the public page and keeps triggering your alerts.
5. Subscribers and the PostShip mention (Pro), Domain and appearance — your own domain and the accent colour (Pro Plus) — see Status domain.

The link is made for a footer: it's the address you open when the site no longer responds, so it must be known before the outage. The embeddable banner (/s/your-address/embed) gives a word and a dot in an iframe — never a script on your side.

Incidents

An incident is born by itself the moment PostShip agrees to write to you — at the N-th confirmation of your rules — and closes by itself at the return to green. In between, from Project → Incidents, you write a 140-character sentence and publish it: the outage is real, telling it remains your decision. 3 states: Investigating, Identified, Resolved. The RSS feed (/s/your-address/rss.xml) carries these published incidents, nothing more. See Incidents.

Subscribers

Your customers leave their address on the page and receive a message at the publication of an incident (“Ongoing incident”) and at its resolution (“Incident resolved”). Nothing in between: a subscriber written to at every state change unsubscribes before the end of the outage. Updating an already published summary doesn't notify twice.

Double opt-in: nothing goes out until the confirmation link has been opened. The form's response is the same in all cases, because answering “already subscribed” would make the page a directory. 3 requests per hour and per IP address. Every message carries an unsubscribe link and the List-Unsubscribe header. The Subscribers card counts the confirmed addresses.

What triggers an alert

Nothing from this page: it reflects your checks and your incidents, with a 30-second cache.

Limits and plans

Showing “100% over 90 days” from 7 days of data would be an invented figure. A return to Discover puts the PostShip mention back. See the plans.

Troubleshooting

Why does the page answer “not found”?

It isn't published, or the address changed. An unknown address and a taken-down page give the same response, so as not to confirm that a project exists behind a guessed address. Go through “Page preview” to see it before publication.

Why doesn't the uptime match my Overview?

The page only counts the displayed components. A hidden or disabled target weighs neither on the percentage nor on the global state — otherwise you'd read “97.2%” under a list of all-green components.

Why did my subscribers receive nothing during the outage?

They're notified at the incident's publication, not at its opening: it's the publication that is the decision to talk to them. An unpublished incident notifies nobody. And only a confirmed address receives something.

Your domain on the status page

Available on the Pro Plus plan.

Publish the status page on status.your-domain.com — the proof TXT, the CNAME, the 3 states, and the accent colour.

By default, the status page lives at postship.fr/s/your-address. The day your site stops responding, it's therefore our name your customers read. On the Pro Plus plan, the same page also answers on a subdomain of yours — status.acme.fr — with a certificate issued by us, and your colour on the title.

What PostShip does

3 moments, in an order that isn't negotiable: accept a name, prove that it belongs to whoever asks for it, then only request the certificate from our host. Nothing is requested before the proof: without it, anyone could have our infrastructure claim a domain that isn't theirs — and serve someone else's page under their own name.

A subdomain, never the bare domain

The address must be a subdomain: status.acme.fr, state.acme.fr, whatever you like. Not acme.fr: the CNAME you'd have to set there would replace the records of your site itself, and it's the most expensive outage you can cause at a client. PostShip refuses a bare domain and says so: “Use a subdomain (status.acme.fr), not the bare domain”. It also refuses postship.fr, vercel.app and localhost.

The field only asks for the prefix (status); the project's domain is shown next to it, fixed, without www.. Retyping your own domain every time is the best way to mistype it — and a typo here creates a domain you don't own, hence a verification that will never succeed. Pasting the whole domain out of habit is accepted.

Set it up

Project → Public → Status, Domain and appearance section. The page must be published first: a domain pointing to a page that's off would show nothing.

1. Enter the subdomain and save. PostShip shows the two records to set at your DNS host.
2. Prove the domain is yours — a TXT record on _postship.status.acme.fr, with the shown value (postship-verification=…).
3. Point the domain — a CNAME record on status.acme.fr, to cname.vercel-dns.com. Propagation takes from a few minutes to a few hours.
4. Click Verify the domain. As long as the TXT doesn't carry the right value, nothing happens and nothing is requested from our host. Once the proof is read, the certificate is requested automatically: “Domain verified. The certificate is issued within minutes.”

Project domain already verified? If you verified the project's domain (Settings → Domain), the proof already covers its subdomains: step 2 goes away, the certificate is requested as soon as you save, and only the CNAME is left to add.

The 3 states

The screen distinguishes 3 moments and never confuses them:

Re-verify re-reads the TXT and requests the certificate again if needed. Remove the domain doesn't turn the page off: it simply goes back to its /s/ address, and an already shared link keeps working.

The accent colour

Same card, same plan: a six-digit hexadecimal colour (#2f6df6). It colours the title and the embeddable banner. The states — green, orange, red — don't change: that's what makes them readable at a glance, and a status page that would no longer be readable would no longer be of any use. Empty, no colour.

What triggers an alert

Nothing: this setting produces no alert. If the TXT is missing, the button answers “No TXT record found. DNS propagation can take a few minutes.”; if it exists with another value, “The TXT exists but doesn't carry the expected value. Check that it's copied in full.”

Limits and plans

Pro Plus only: it's the setting that assumes someone able to touch a company's DNS, and it commits our infrastructure to carrying a certificate for a domain that isn't ours. See the plans and the pricing.

Troubleshooting

Why “Verified — certificate in progress” for more than 10 minutes?

The CNAME may not be propagated yet, or points elsewhere than cname.vercel-dns.com: the certificate can only be issued if the name reaches us. Check with dig status.acme.fr CNAME, then click Re-verify.

Why isn't the TXT found when I set it?

The name must be exactly _postship.status.acme.fr — at some hosts, the “name” field expects _postship.status only, the suffix being added. A long TXT is sometimes split by DNS into segments; PostShip glues them back, that's not the cause.

Why does my page answer “not found” on my domain?

2 conditions, and both count: the domain must be verified, and the page published. A registered but unproven domain renders nothing, even if the CNAME is in place.

Maintenance calendar

The maintenance windows announced on the status page, over 30 days, and the .ics feed your clients drop into their calendar.

A client planning a campaign wants to know when your site will be under maintenance — not to come and check the page every week. The status page announced a one-off window within 24 hours; it said nothing of “every Sunday from 3 am to 4 am”, when that's precisely what they want to know. The calendar unrolls both — the one-off window and the recurring rule — over a horizon, and writes them in iCalendar format.

What PostShip does

The windows come from the project's maintenance settings: a one-off window (start, end, reason) and a weekly rule (days, start time, end time, time zone, reason). The calendar unrolls them over 30 days, in order, 12 occurrences at most — a calendar of 12 Sundays is enough to understand the rule.

The weekly rule is unrolled day by day in its time zone: each ticked day gives a window that starts that day at the start time; if the end time is before the start time, the window ends the next day (11 pm → 2 am). Local times go through the same converter as the forms — it's the one that knows about daylight saving. A window started the evening before and still running this morning is included.

On the status page

When at least one window is planned, the public page shows a Planned maintenance section with the next 5 occurrences and the link “Add to my calendar (.ics)”. An ongoing window takes precedence over the components: the page title becomes “Maintenance in progress”, with the reason (or “Planned intervention.”), because someone stands behind this interruption and that's what the reader must read first. A one-off window starting within 24 hours is announced at the top of the page.

The section doesn't exist when nothing is planned: showing “no maintenance” would be a promise the page can't keep.

The .ics feed

At the address postship.fr/s/your-address/maintenance.ics. Google Calendar, Outlook and Apple Calendar all read an iCalendar feed: the windows appear in the client's calendar, updated on every re-read. Each occurrence has a stable identifier (the page's address and the start time): a calendar that re-reads the feed updates the event instead of duplicating it. The calendar is named “Maintenance — your title”, each event “Maintenance — your title”, with the reason as description when there is one.

Same rule as the RSS feed: nothing more than what the page shows, and the same response (“not found”) for an unknown address and an unpublished page. The feed is cached for 10 minutes.

Set it up

Project → Alerts → Maintenance: a one-off window on the calendar, or the weekly rule.

• Maintenance window: a start, an end, a reason. During the window, alerts go quiet and the badge shows “maintenance” rather than “passing”.
• Recurring maintenance: one slot per sentence, “Every M T W from 03:00 to 04:00”, as many slots as needed (ten at most), one time zone for all. “Remove” takes a slot away.

Nothing to do on the status page itself: it reads the same settings. For your clients to see the calendar, the page must be published.

What triggers an alert

Nothing from the calendar. It's the other way round: during an announced window, the project's alerts are held back — see Maintenance for what exactly goes quiet and what is caught up afterwards.

Limits and plans

The calendar and the .ics feed follow the status page, on every plan; planning the windows requires Pro, like the rules and the Maintenance page. No limit of its own: 30 days of horizon, 12 occurrences, 5 shown on the page.

Troubleshooting

Why is the .ics feed empty?

No window falls within the next 30 days: a past one-off window is no longer listed, and a recurring rule without a ticked day doesn't exist. The file is valid, it simply contains no event.

Why does my calendar show the window one hour off?

The rule is unrolled in the time zone chosen in the settings, and the times are written in UTC in the feed, as the standard requires. Check the rule's time zone — not your account's — especially around a clock change.

Why does the status page only show 5 windows when the rule is weekly?

The page shows the next 5 to stay short; the .ics feed carries up to 12. A client who wants more subscribes to the feed.