Badge and sharing

One SVG badge per project, opt-in — pass/fail only, no history, no URL list, no incident log. It answers “not found” until you've explicitly enabled it from the Report page (Project → Public → Report). It isn't a status page: for that, there is the status page.

What PostShip does

The badge lives at postship.fr/badge/<project-id>. A 140 × 20 pixel image, in the shields.io style: “PostShip” on the left, the state on the right, 2 flat colours and nothing else — no gloss, no gradient, one bit of information.

During an announced maintenance window, the badge says “maintenance” rather than “passing”: a reader deserves to know that the checks aren't the point right now, and “up” would be a claim nobody guarantees.

The living badge

Same address, with ?ship: postship.fr/badge/<project-id>?ship. Instead of the state, the Ship Score of the last deploy — “ship | 94” — which updates by itself wherever you pasted it: README, a client site's footer, a status page. Green from 90, orange from 70, red below; a dash until a deploy has been tracked. It follows the same switch as the state badge, and says “maintenance” during an announced window.

The image is served with a one-minute cache. It carries no URL, no check detail, no personal data: only the project's summarised state gets out.

Set it up

Project → Public → Report, Public badge card → Enable the badge. The page then shows both badges and their Markdown to copy: a Markdown image whose source is https://postship.fr/badge/<project-id>, wrapped in a link to https://postship.fr. Copy it from the page rather than rebuilding the address. In HTML, the same image in an img tag with a link around it:

<!-- In an HTML README, a help page, a footer -->
  <a href="https://postship.fr"><img src="https://postship.fr/badge/<project-id>" alt="PostShip" width="140" height="20"></a>

Disable makes the address answer 404, immediately (give or take the cache): a README that still displays it shows a broken image, not a stale state.

The rest of the Report page

The Report page gathers what your visitors and clients see of this project, without access to your dashboard:

• Social cards: the real preview of every page that has an Open Graph check — title, description, image, as the networks will display them.
• Public badge: this page.
• Deploy card: an unlisted public page with the last deploy's score — see Deploy card.
• Read-only links for a client: a psl_… link that opens the project read-only. An agency monitoring its client's site wants to show it to them without giving them a collaborator account — which would see the API tokens, the billing, the other projects. The token isn't kept, only its fingerprint is: a lost link is revoked, it isn't found again. It expires after 90 days, because a read link that never expires ends up circulating — in a thread, in a ticket, at the next contractor. An unknown, revoked or expired link answers exactly the same thing. On Pro Plus, this link is the client portal: the header carries your white label and the client site's icon, and the status page and the report, when public, are one click away. No token, no invoice, nothing that is the agency's business.
• Magic link: the same page, on every plan, for 7 days — “show this to my co-founder”. The site's state and the last deploy, read-only, no account. 3 active magic links per project at most; on Pro Plus, client links last 90 days and carry a name.

What triggers an alert

Nothing: the badge and the links reflect the state, they don't evaluate it. What changes the colour are your checks (HTTP and assets, payment pages, etc.).

Limits and plans

See the plans.

Troubleshooting

Why does the badge show “pending” when my checks are running?

The badge reads the project's summarised state, written at the end of each run. On a brand-new project, the first run may not be finished: the first check runs when the URL is added, and the cycle follows every 1 to 5 minutes depending on the plan — on Pro Plus, the 30-second probe triggers a run as soon as a page changes state.

Why does the badge stay green when a URL is failing?

One minute of cache. The project's state is recomputed after each run — and after each “Check now” — from the last verdict of all active targets: a single one in fail or error is enough to turn it red. If the badge stays green, the target in question is disabled, or its verdict hasn't been written yet.

Why does my README show a broken image?

The badge is disabled (404), or the project id was copied wrong. Copy the Markdown from the Report page rather than rebuilding the address.

Deploy card

Available on the Pro and Pro Plus plans.

The unlisted public page that answers “is the site doing fine?” with the last deploy's score, without opening the dashboard.

A founder sends the badge to a client and gets “is that all?”. The deploy card is the page that answers that question, and nothing else: the project name, the last deploy's score and its reason, the last 8 scores as bars, and the type of the points still open. Never a URL, never an uptime percentage, never personal data. Designed to be sent to a client, it gives no access to the dashboard.

What the card shows

At the address postship.fr/ship/<token>, forbidden to robots (noindex):

• Last verified deploy: the Ship Score of the last production deploy — never a preview — green from 90, orange from 70, red below; the reason for the grade (“−25 missing asset”) or “Everything passed.”; and since when.
• The last 8 deploys as bars, coloured the same way. A score of 0 stays a visible bar, not a blank the eye would read as missing data.
• Purchase journey: “n / n” of the payment pages green — the count, never the addresses, because the URLs themselves would draw the payment journey. “Payment, login and price verified.” or “A step of the journey no longer responds as expected.”
• What this deploy changed: the number of pages whose title, H1, description or social card moved since the previous deploy, according to the deploy diff. The name of the fields, never their content.
• Open points: the type of the 3 oldest failing targets (“HTTP”, “Certificates”, “Journey”) and since when — not their URL, which would say which parts of the site exist and which are broken.
• During a maintenance window, the card announces it with the reason, instead of the score.

A project without a verified deploy shows “No verified deploy yet.”

The “what this deploy changed” page

From the card, “See the detail: before / after” opens postship.fr/ship/<token>/changes: the deploy diff made shareable. Page by page, what moved between the last production deploy and the previous one — the title, H1, description and og:title before / after; the og:image before / after as images (the before image comes from the archive, even when its URL no longer answers); the prices before / after recorded by the price canary; and the broken assets (scripts, stylesheets, images that no longer answer). Unchanged pages are folded at the bottom. ?d=<deploy id> pins the page to a given deploy — the id is the one from the Deployments page, not a guessable sequence.

It's what an agency sends its client instead of “it's live”, and what an indie pastes into their changelog. Unlike the card, this page shows the monitored URLs and their public content — what a visitor of the site already sees — but nothing of the settings, tokens or previews. Same token, same switch, same plan as the card.

Set it up

Project → Public → Report, Deploy card card → Enable. The page shows the address to copy and a link to open it.

The token (32 hexadecimal characters, drawn at random) is minted once and kept: disabling then re-enabling the card keeps the same address, so a link already sent to a client keeps working. The card is unlisted rather than secret: the token in the address is the only thing between a stranger and the page, and there is no button to regenerate it.

Disable makes it answer “not found” — the same response as a wrong token, so as not to confirm that a project exists behind a guessed address.

The weekly digest by email (Account → Notifications) includes the card's link when it's active.

What triggers an alert

Nothing: the card reflects the deploys and the checks. What moves it are the deploy webhooks, the score, and the state of the targets.

Limits and plans

The same line as the other deploy features: a Discover project has a handful of URLs and 7 days of history, the card would be an almost empty page with the client's name on it. A card enabled then downgraded to Discover answers “not found”: the card is paid for, so it's taken back — and its setting stays reachable to remove it. See the plans.

Troubleshooting

Why does the card say “No verified deploy” when I deploy every day?

Only graded production deploys count. Without a connected host or fingerprint detection, PostShip doesn't know a deploy happened. Previews are never shown here: a preview checked 2 minutes ago says nothing about what's live.

Why don't the open points name the broken page?

Deliberate. The card is made to be forwarded; a URL would tell any recipient which parts of the site exist and which are down right now. The type and the age are enough to answer “is it serious?”.

Why did the link stop working?

The card was disabled, or the owner's plan went back to Discover. The token itself never changes: re-enabling makes the same link valid again.

Shareable report

The unlisted page you send to a client who asks “so, how was this month?” — uptime, incidents, deploys, error budget, site checks.

What an agency sends its client at the end of the month, with no screenshot or export: a public, unlisted page, behind a token. Uptime, incidents, deploys, error budget, site checks — over the window the plan keeps. Nothing that identifies a person, no monitored URL other than the site itself, no failure detail: the client reads a summary, not a dashboard. A page that prints.

What the report shows

At the address postship.fr/rapport/<token>, forbidden to robots (noindex), over the last N days (N = the plan's retention, 30 at most):

• The summary in one sentence, the one you read before the figures: “Uptime 99.97% over 30 days, 2 incidents, 9 deploys including 1 failed.”
• Uptime: the rate of successful checks over the period, to 2 decimals, with the total number of checks. All the project's targets count, including the site checks.
• Incidents: the incidents opened over the period (50 at most), with their summary, start date and duration (“12 min”, “1 h 05”, “ongoing”). Published or not: these are incidents in the application's sense, not only those told on the status page.
• Deployments: the number of production deploys over the period, and how many failed. Never a preview.
• Uptime target and error budget, if the project has a target: “X of estimated downtime out of Y tolerated”. The possible targets are 99%, 99.5%, 99.9%, 99.95% and 99.99%.
• Site checks: each active check with its last verdict — “green”, “to fix”, “inconclusive”, “not checked yet” — and the count “n of m green”. The check's name, never the detail of what's missing.

The footer states the method: checks happen after every deploy and at a regular interval, and uptime is the rate of successful checks.

Set it up

Project → Public → Report, Shareable report card: the Enable the link switch, which saves by itself. The link is displayed permanently with a button to copy it; as long as it isn't enabled, it answers “not found”.

The token (32 hexadecimal characters) belongs to the project and doesn't change: turning the report off then on makes the same link valid again, so the one already sent works again. An unknown token and a disabled report give the same response.

The uptime target is set in Project → Settings → Monitoring, Uptime target row: without a target, the report has no error budget section.

What triggers an alert

Nothing from the report: it reads what the checks, the incidents and the deploys wrote.

Limits and plans

The window is the one of the retention: a report that claimed to cover a month with 7 days of data would be empty at its end, which reads as “no incident” rather than “no data”. See the plans.

Troubleshooting

Why does the report's uptime differ from the status page's?

The status page only counts the displayed components; the report counts all the project's checks, site checks included. A check in error for 2 days weighs on the report, not on the status page if it isn't on it.

Why does an incident appear here when I didn't publish it?

The report is made for a client you owe an account to, not for the public: it lists the real incidents of the period, published or not. If an incident must not appear there, it's the link you must not send.

Why does the report say “No check over the period”?

The project is paused, or has no active URL. The sentence is honest rather than reassuring: without a check, there is no uptime to announce.

Monthly report to your clients

Available on the Pro Plus plan.

On the 1st of the month, the past month's report goes out by email to the addresses of your choice — for agencies that report to their own clients.

The shareable report is a page you send by hand when the client asks “so, how was this month?”. The monthly report is the same summary, without having to think about it: on the first of every month, the past month goes out by email to the addresses you gave — your client, their technical lead, whoever you want. You have nothing to do on the 1st, and the client has nothing to ask.

Set it up

Project → Public → Report, Shareable report card, Monthly report by email section. One address per line, 10 at most, then Save. Emptying the list stops the sending.

Send me a preview of last month sends you, right now, exactly what the recipients will receive for the past month — to judge before the 1st decides. The preview carries “[Preview]” in its subject.

What the client receives

An email “Acme — August 2026 report”, from PostShip, where replying writes to the project owner — you are the one the client knows, not us. Inside:

• the summary in one sentence: “Uptime 99.93% over 31 days, 1 incident, 14 deploys including 1 failed”;
• the figures: uptime, checks, incidents, deploys, error budget if a target is set, and the state of the site checks — “6 green” or “1 to review: SEO tags”;
• the list of the month's incidents, with their date and duration, as they were published;
• the link to the online report, if the shareable report is enabled.

Like the shareable report: no monitored URL other than the site, no failure detail, nobody named. The client reads a summary, not a dashboard.

White label (Pro Plus)

On the workspace page, White label: your name and your logo (an https address). From then on, the header of the report email and page carries your brand instead of PostShip, and the line becomes “Report produced by Coral Studio from the site's automatic checks”. The email's legal footer stays: the technical sender is PostShip, and an email has to say so. It's your deliverable of the 1st, not one more email signed by a third party. One brand for every site of the workspace; an empty name removes it; after a downgrade, the header is PostShip again without touching the setting.

The month

A closed calendar month, in the project's time zone (the one of the quiet hours, Paris by default): “August 2026” means from 1 to 31 August, not “the last 30 days”. The sending goes out on the first run after 8 am on the 1st of the month. A project that enables the report on the 20th receives the previous month on the next run — then the following ones on the 1st.

Each month is sent only once per project, even if 2 runs cross.

Limits and plans

Pro Plus plan: it's the plan of those who report to their own clients. 10 recipients per project. Data goes back as far as the plan keeps it (90 days for Pro Plus): a whole month fits inside.

Troubleshooting

The report didn't go out on the 1st

Check that the list isn't empty and that the project is on the Pro Plus plan (the card says so). The sending happens on the first run after 8 am in the project's time zone: a zone set to Nouméa goes out while Paris is still asleep. The card shows the last month sent.

A recipient doesn't receive it

The email goes out from PostShip's address, with the project name in the subject. Ask the recipient to look at their spam, then to add the sender to their contacts. If the address rejected the email, write to us from Help: we look at the sending trace.

Post-mortem

An incident's post-mortem in Markdown, ready to paste, and the unlisted link to share it with a client then withdraw it.

After an outage, you have to write down what happened: for the team, for a client, for next time. PostShip already has the timeline — the first failure, the confirmations, the preceding deploy, the return to green — and a probable cause. The post-mortem puts them in a Markdown document, to paste in a wiki or a ticket, or to share through an unlisted link you can withdraw. What the client reads is exactly what the team read.

What the document contains

Times in UTC, announced in the timeline's header, because those are the ones of the logs you'll go read. No emoji: this document is read cold.

• The header: “Post-mortem — ” followed by the incident summary; the project and its address; start, end (or “ongoing”) and duration.
• Impact: the affected URL, the error recorded, and the other targets at the same time — “none of the 7 others failing, the outage is specific to this page” or “3 of 7 failing at the same time”.
• Timeline (UTC): one line per event, with the time, the delay relative to the start (“3 min before”, “at the time of the outage”, “1 h 12 min after”) and the text: first failure, previous deploy, taking charge, escalation, return to green.
• Probable cause: the main hypothesis in bold with its confidence level (strong, medium, weak) and its evidence, then the other hypotheses kept. The possible causes: Deploy, Provider incident, DNS change, Certificate, Regional network, Third-party script, Saturation, Whole-site outage, Announced maintenance, Unknown cause. The rules that tell them apart are on the Probable cause page.
• What PostShip didn't see: the caveat, always. PostShip observes from the outside; the server logs, the internal metrics and the configuration changes outside a deploy are not in this timeline. When the confidence is weak or the cause unknown, the document says so in plain words: what precedes is a weak correlation, not an explanation.
• Taking charge: who took the incident, how long after the start, and the escalation to the whole team if it happened — or “Nobody took charge of this incident.”

Set it up

Project → Incidents → the incident. Under the timeline, the Post-mortem card:

1. Copy: the button copies the whole Markdown (the card shows its number of lines). Paste it in your wiki, your ticket, your channel.
2. Share through a link: tick the box, then Save. The link postship.fr/pm/<token> appears with a copy button. The public page carries the same content, the title “Post-mortem · project name”, and “Generated by PostShip · times in UTC” in the footer.
3. Withdraw: untick, Save. The link now answers “not found”.

A fresh token on each share: withdrawing then re-sharing changes the link, and the old one doesn't reopen. It's the opposite of the deploy card, whose link is made to last — a post-mortem shared with a client for a given outage isn't meant to stay open. The page is forbidden to robots.

A read-only member can copy the Markdown but can't share or withdraw the link.

What triggers an alert

Nothing: the post-mortem is a document, it doesn't monitor. What feeds it: the incident itself, the taking charge, the escalation, and the signals the probable cause picked up.

Limits and plans

Available on all plans, for every incident. The signals re-read for the probable cause come from the project's history, hence from the plan's retention window.

Troubleshooting

Why is the probable cause “unknown”?

No decisive signal around the start of the outage: no recent deploy, no DNS drift, no provider incident, no other failing target. The document then says that the server logs around the start time will tell more. It's an honest answer, not a defect.

Why doesn't the shared link work anymore?

Someone unticked “Share through a link”, or unticked then re-ticked: the token changes on each share. Copy the link shown now on the incident page.

Why aren't the document's times mine?

The Markdown and the public page are in UTC, to match your server's and your host's logs. In the application, the incident's timeline is shown in your time zone.