Uptime monitoring

Every run makes one HTTP request and records three things: whether it answered, how long it took, and what status code came back. A non-2xx response, a connection failure or a timeout all count as down.

Default interval

5 minutes

Request timeout

30 seconds

Slow-response alert

5000 ms

Writes the uptime %

Yes

The alert threshold is separate from the timeout. A site that answers in eight seconds is up — but it is also broken in a way worth knowing about, so crossing the threshold raises a slow-response alert without opening a downtime incident.

Pulse records a metric row for uptime checks and for nothing else. That is a deliberate constraint, not an oversight.

The uptime percentage, the response-time charts and the org-level statistics all read from that one table. If a certificate check or a DNS check also wrote to it, then “uptime” would quietly come to mean “the percentage of checks of any kind that passed” — a number that drops when your DNS drifts and that nobody can explain to a customer.

The most expensive outages are the ones that answer. A checkout page that returns 200 with a stack trace in the body, a homepage serving a cached maintenance notice, a search page rendering zero results because the index is gone — an uptime check calls all of those healthy, because they are.

A content assertion is the companion check. You give it a string or a regular expression and say whether it should be present or absent. Assert that “Add to cart” is present, or that “Something went wrong” is absent, and the check fails on the thing your users would actually notice.

One honest limit: it reads the HTML the server sent and does not execute JavaScript. On a client-rendered app, the text you are asserting on may not exist in that HTML at all — assert on something the server renders, or a shell that is always present.

These are two different mechanisms and it is worth knowing which one is talking to you.

An incident is a state. It opens the moment a check transitions to failing, notifies immediately, stays open while the problem persists, and closes itself when a run passes again.

An alert rule is a threshold you set — response time over a value, uptime under a percentage. Breaches are collected and sent as a periodic digest rather than individually, because a rule whose message embeds a moving percentage produces a new row on every single check.