Almost everyone arrives with a tool in place, and it does its job well. Pick yours: the table says where it stops, where PostShip stops too, and what each one costs at equal volume.
You already have
What UptimeRobot does. The best-known uptime probe: it requests your page every 5 minutes (down to every 15 seconds if you pay) and warns you when it stops answering.
Line by line
UptimeRobot
PostShip
The server answers (HTTP 200)
Yes
Yes
An interval under a minutePro Plus probes every page every 30 seconds and runs the full check at the slightest change (on top of a full pass every minute); PostShip also checks on every deploy.
Yes
Yes
Ping, TCP port, UDP
Yes
No
An expected word on the pageWith them a keyword; with PostShip the price, the button and the script, on every page of the funnel.
Yes
Yes
The certificate and the domain that expire
Yes
Yes
Phone call and SMSPostShip alerts by email, Slack or Discord.
Yes
No
Mobile appPostShip installs as an app from the browser.
Yes
No
Public status page
Yes
Yes
Checks the second you deploy, previews includedA probe passes at its own pace and hopes to stumble on the failure.
No
Yes
The price, the button, the payment script are actually on the pageA dead checkout answers 200 like the others.
No
Yes
The checkout journey, replayed in order
No
Yes
The domain actually serves the new build (CDN cache, alias, DNS)
No
Yes
A deploy that breaks is withdrawn, by hand or on its ownVercel, through the integration.
No
Yes
The share image, indexability, the sitemap
No
Yes
The monthly report sent to your clients
Not found on their site
Yes
Interface, alerts and support in French and English
Not found on their site
Yes
A tool missing? Write to us from support, and tell us if a line looks wrong to you: it will be corrected, in either direction.
What we're often asked
No, and most accounts keep both. A probe watches the machine — the server answers, the port is open — and PostShip watches the page as a customer sees it, at the exact moment you change it. They don't step on each other.
Check at deploy time. They run at a fixed interval; PostShip is told by the host and checks at T+0, T+2 and T+8 minutes, when the cache is warm. A bad deploy is seen within the minute, not at the next pass.
Because that isn't the question it asks. An open port doesn't say anyone can pay. PostShip loads the page, its scripts, its payment button, its certificate, its sitemap: what breaks when you go live, not what breaks when a cable drops.
They are recorded by hand on their pricing page, on a date written under each table. When they move, we redo the reading and the date changes. Ours come from the same source as the pricing page: they can't drift.
For a server outage, on Discover and Pro, yes: a 30-second probe will see it before us. On Pro Plus, PostShip probes every page every 30 seconds and runs the full check at the slightest change: the outage is spotted just as fast. For a deploy, the interval doesn't matter: PostShip checks the second the host announces the release.
You paste your site's address and PostShip suggests the pages to watch from the sitemap and the home page links. There's no file import, because there is nothing to import other than addresses.
Yes, and ours is of the same kind: components, 90-day history, published incidents, subscribers by email, Slack or webhook. The difference is elsewhere: it is fed by the checks of your pages, not only by a ping.
Read the “is the right choice if” column under the table. If your trouble comes after a release — a script that no longer loads, a price that vanishes, a silent form — it's PostShip. If your server goes down without you deploying anything, it's the probe.