Checks & monitors

Requests a URL and evaluates the response: a healthy status code counts as up, a timeout or a server error counts as down. Runs from RealUptime's own cloud probes, so it can only reach targets that are reachable from the public internet. Use the Monitor agent instead for anything behind a firewall.

Opens a connection to a host and port and confirms it accepts one, the right check for a database, a cache, or any service that speaks its own protocol rather than HTTP. Can also complete a TLS handshake and track the certificate's expiry, warning you before it lapses. See TCP checks for the full detail.

Resolves a hostname and confirms the record still exists, optionally checking it against an expected value. Leave the expected value blank to alert only when the record stops resolving entirely, or set it to also catch a record that still resolves but no longer points where it should, a repointed record that looks healthy to every other kind of check.

The inverse of the other three: instead of RealUptime reaching out, your job checks in with RealUptime on its own schedule. Built for cron jobs, backup scripts, and queue workers that run on a schedule rather than serving requests. See heartbeat monitors for the ping contract, arming, and the grace period.

HTTP, TCP, and DNS checks run every 60 seconds from each region you select. Heartbeat monitors run on whatever interval your job dictates, from 60 seconds up to 24 hours, plus a grace period you set for extra slack past the interval before a late ping counts as down.

RealUptime's cloud probes check from four regions: US-East, US-West, Europe, and Asia-Pacific. Pick which of the four probe an HTTP, TCP, or DNS check when you create it, all four by default, and change the selection later from the check's own settings. A heartbeat check has no region: nothing reaches out for it, so there is nothing to select. The Monitor agent has its own region too, wherever you run it, alongside the four cloud regions on any check it is bound to.

By default an HTTP check is up when the status code looks healthy. Response assertions let you confirm the page is actually right, not just reachable: the body contains (or does not contain) text you choose, a response header matches a value you set, or the status code falls in a range you pick instead of the default. Add them from the check's create or edit form, under "Response assertions."

A failed assertion counts the check as down, with the specific reason shown on the check's row and detail page, for example "Body is missing 'Add to cart'" instead of a generic failure. It flows through the same alerting as any other down check: your operator channels hear about it the same way, and a public status page (if the check is attached to one) reports the same outage it would for a timeout or a server error. Works identically whether the check runs from RealUptime's cloud probes or your own Monitor agent.