Uptime monitoring
PostDeploy requests your URL on a schedule and opens an incident when it fails or responds too slowly. Checks are HTTP or keyword, the failure threshold is yours to set, and uptime is computed from incidents rather than by counting check rows.
What an uptime check does
Each check makes one HTTP request to the URL you gave it, on the interval your plan allows, and records the status code and how long the response took. You choose the method, any headers, whether redirects are followed, and the timeout.
A keyword check adds one assertion to that request: the response body must contain, or must not contain, a string you specify. This is what catches the failure mode a status code misses, where the server returns 200 with an error page or an empty template.
When a failure becomes an incident
A failed check does not alert on its own. The failure threshold defaults to 2 consecutive failures and can be set from 1 to 5, which is the dial between catching a short outage and being woken by a blip. Recovery is fixed at 2 consecutive passes, so a flapping endpoint does not resolve and reopen repeatedly.
When an incident opens, every notification channel on the monitor is notified. Acknowledging stops reminders without closing the incident. If you want to be reminded while it is still open, set the monitor to resend after a number of failed checks.
How uptime is calculated
Uptime is time-weighted from incident start and end times, not a ratio of failed to total check rows. Those two methods disagree whenever the check interval changes or a check is missed, and the incident-based number is the one that matches what your users experienced.
Paused time is excluded from both the numerator and the denominator. Pausing a monitor during planned maintenance neither inflates your uptime nor counts against it.
Check intervals and retention by plan
The interval floor is the main thing plans buy down: 1 minute on the trial and Pro, 5 minutes on Indie, 30 seconds on Scale. The interval sets your worst-case detection time, so a 1-minute floor means an outage can run for about a minute before the first failed check.
Detailed samples, meaning individual check results, are kept for 30 days on the trial and Pro, 7 on Indie and 90 on Scale. Past that window results fold into daily uptime history.
Questions
How quickly will PostDeploy notice an outage?
Worst case, roughly one check interval plus the failure threshold. On the trial, with 1-minute checks and the default threshold of 2, that is about two minutes to an alert. Lower the threshold to 1 to alert on the first failure, at the cost of more false alarms.
Can PostDeploy check a page behind authentication?
Yes, if the authentication fits in a header or a request body. You can set the method, headers and body on a check. There is no browser-based login flow, because PostDeploy does not run browser checks.
Does a slow response count as down?
Only if it exceeds the timeout you set on the check, in which case the check fails. PostDeploy records latency for every check, but it does not open an incident purely for a response that got slower.
Ship your next project with one toolkit, not three.
Sign up and every feature described on this page is yours on the trial. No credit card.
Create your first monitor