Introduction

PostShip checks your site like a real visitor, right after every deploy and then every 5 to 30 minutes: HTTP status, JS and CSS files, Open Graph preview, sitemap, certificate, forms, payment journey, API contracts. You are only told when something breaks — silence when everything is green.

How it fits together

A project stands for a site: its production domain. Inside it, monitored URLs — the home page, the checkout, a login page — each with its own kind of check. On every run, PostShip requests each URL and writes a result: pass, fail or error. A fail opens an incident; going back to green closes it.

Where to start

1. Create your first project and add a URL: the first check runs immediately.
2. Connect your host so that every deploy is checked the second it lands.
3. Choose where to be told: email by default, Discord or Slack.
4. Let it run. The site checks and the Performance page fill up on their own.

What this guide contains

• Checks: each kind of URL, what it looks at, what makes it fail.
• Deployments: the verified ship, the Ship Score, the diff, previews, the freeze.
• Alerts & incidents: channels, silence rules, taking charge, probable cause.
• Performance & visitors: response time, real vitals, your visitors' errors, the 5 continents.
• Security & integrity: third-party scripts, headers, exposed files, certificates, DNS.
• Public pages: the status page, the badge, the reports.
• Automation: the API, CI and the CLI.
• Account & plans: what each plan allows.

Vocabulary

The 10 words the application uses everywhere, and what exactly they designate.

PostShip has a short vocabulary and uses it strictly: a “run” isn't a “check”, an “incident” isn't an “alert”. This page defines each word once, as it appears on screen, in the emails and in the API.

Project

A site: its name and its production domain (https://acme.fr). Everything PostShip monitors lives in a project, and every URL added must belong to that domain or a subdomain. The alert settings, the connected host, the public status page are attached to the project. See First project.

Monitored URL (target)

An address PostShip requests, with a kind of check. The application says “monitored URL”; the API and the code say “target”. A target has a last verdict, a streak of consecutive failures, and can be disabled: it then keeps its last result as a trace, without counting as an outage.

Kind

What is checked on a target. Those you add yourself: HTTP, OG / Twitter, Sitemap, SSL, Form, API contract, Journey, Heartbeat, and the Payment check. Those PostShip creates for you, one per project: Indexability, Security, Cookies, Redirects, Tags, Leaks, Exposed files, Third-party scripts — those are the site checks.

Run

One execution of a target, at a given moment. Each run writes a result:

A run also carries the HTTP status, the response time (TTFB) and a fingerprint: the outage's signature (verdict + status + gaps). 2 runs failing for the same reason have the same fingerprint; that's what avoids re-alerting you on every cycle for the same thing, and what re-alerts you when the outage changes nature (a 503 turned 404).

Runs are triggered by the cycle (every 5 min on Discover, 2 on Pro, 1 on Pro Plus), by the Pro Plus 30-second probe when a page changes state, by a deploy, by T+2 and T+8, or by “Check now”.

Incident

An active target whose last run is fail or error. It opens at the first red verdict and closes at the return of green; the project's Incidents page lists the open ones, with a sentence naming the cause. A disabled target never has an open incident.

The alert is something else: it's the message sent. By default it goes out at the first failure; with the confirmation (Project → Alerts → Rules, “Alert after 2 failures in a row” or 3), the incident exists from the first failure but the alert waits for the confirmation. The journal distinguishes 4 events: “Failing”, “Recovered”, “Content changed”, “DNS drift”. See Incidents and Rules.

Ship

A deploy in production, and the check that comes with it. When your host tells PostShip (webhooks), all the project's targets are run again immediately, then two and eight minutes later. The Deployments page keeps each deploy with its verdict, its diff and its score.

Ship Score

A grade out of 100 after every deploy, computed without a language model: we start from 100 and remove points per category of gap.

2 failing payment pages cost twice 40; 4 failing site checks cost 10 in total — a site that sells well must not fail its ship over 4 tags. On Pro Plus, the GitHub Check can require a minimum score. Detail on Ship Score.

Outside the quota

The targets PostShip creates itself (the site checks) don't count in the plan's URL quota: you didn't ask for them, billing them would amount to shrinking your plan without saying so. Everything you add counts — including a journey (one URL, not 4) and a heartbeat.

Site checks

The 13 checks set on the site's origin and which run only on deploy (webhook, T+2 / T+8, “Check now”): what robots.txt allows, the security headers, the cookies, the redirects only change at release, and asking for them again every 5 minutes would redo the same request for the same response. They're read, and turned off one by one, in Project → URLs, where each has its row. On Discover, their verdict is computed and shown, but the alert isn't sent. See Site checks.

Gap and warning

In a site check, a gap puts the target in failure and triggers the alert; a warning is noted on the target's page without triggering anything. A missing <title> is a gap for the tags; a too-short <title> is a warning. Each check page lists both separately.