Monitoring for the project you actually ship
PostDeploy checks the URLs you serve and the jobs you schedule, from one project, on one plan. Uptime and API checks watch anything with an endpoint. Heartbeats watch anything scheduled, where the failure is silence rather than an error. The trial covers 100 uptime and API monitors and 200 cron and heartbeat jobs, no credit card required.
What PostDeploy monitors
Two questions cover most of what breaks in a small production system: is the thing I serve responding, and did the thing I scheduled actually run? PostDeploy answers both from the same project, so you are not reading two dashboards to find out.
- Uptime checks (HTTP): request a URL on a schedule and open an incident when it fails or is too slow.
- Keyword checks: the same request, plus an assertion that the response body does or does not contain a string.
- API checks: methods, headers and request bodies, with expected status codes.
- TCP checks: open a connection to a host and port, for things that are not HTTP.
- DNS checks: resolve a record and assert the answer, with optional CDN-provider awareness.
- Heartbeats: your scheduled job pings PostDeploy, and silence is the failure signal.
- SSL and domain expiry warnings: notified 14, 7 and 1 days ahead.
What PostDeploy does not do
Stated plainly, because finding out after you migrate is worse than reading it now.
There are no ICMP ping checks and no UDP checks. There is no browser or transaction checking, so a multi-step signup flow in a real browser is out of scope. Checks run from a single region, so PostDeploy cannot confirm a failure from a second location before alerting, and a regional network problem between us and you can read as downtime. There is no on-call rotation or escalation policy: PostDeploy opens an incident and notifies your channels.
How a check becomes an alert
A check runs on your interval. A failure does not alert immediately: the failure threshold defaults to 2 consecutive failures, adjustable from 1 to 5, so a single blip does not wake you. Recovery is fixed at 2 consecutive passes.
When the threshold is crossed, PostDeploy opens an incident and notifies every channel you configured. Acknowledging an incident stops reminders without closing it. Uptime is computed time-weighted from incidents rather than by counting check rows, and paused time is excluded from both sides, so pausing a monitor never flatters or damages the number.
Where to start
If you serve a URL, start with an uptime check. If you schedule a job, start with a heartbeat, because that is the failure no uptime check can see. Most projects want a few of each, and the two allowances are separate on every plan, so watching a scheduled job never consumes an uptime monitor.
Questions
How many monitors does the trial include?
10 uptime and API monitors and 20 cron and heartbeat jobs, on separate allowances, with a 5-minute minimum check interval and 7 days of detailed check samples.
Does PostDeploy check from more than one region?
No. Checks run from the PostDeploy application servers in a single region. That means no multi-location confirmation before an alert, which is a real limitation if you need to distinguish your outage from a network problem on the path to you.
What is the difference between an uptime check and a heartbeat?
An uptime check is PostDeploy asking your URL whether it is alive. A heartbeat is your job telling PostDeploy that it ran. Uptime checks catch things that respond incorrectly; heartbeats catch things that stop happening, which produce no failing request to poll for.
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.
Start monitoring