Checks & monitors

HTTP

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.

TCP

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.

DNS

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.

SMTP

Opens a connection to a mail server, reads its greeting, and completes the opening handshake, so it catches the failure a TCP check on port 25 cannot: a mail server that accepts the connection and then never answers. An overloaded mail server, a load balancer in front of a dead backend, and a tarpit all look perfectly healthy to a check that only opens a socket. Optionally requires STARTTLS to negotiate successfully too, so an expired or broken certificate on the mail path shows up as a real failure instead of quietly downgrading.

It never signs in and never sends mail. There is no username, no password, and no test message: the check ends after the handshake, so nothing you configure here can be used to send anything. Ports 25, 465, 587, and 2525 are supported.

Ping

Echoes a bare host and reports round-trip latency and packet loss over several probes, no port and no application protocol required, the check to reach for a router, a printer, or any device that speaks neither HTTP nor a known TCP service. See Ping checks for how it measures latency and loss without raw ICMP.

Heartbeat

The inverse of the other four: 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.

Intervals

HTTP, TCP, DNS, SMTP, and Ping 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.

Regions

RealUptime's cloud probes run from ten regions: US-East, US-West, Europe, Asia-Pacific, US-Central, Canada, UK, Southeast Asia, Australia, and South America. How many of them a monitor may use is set by your plan: four regions on Free, eight on Growth, all ten on Scale. Pick which of your plan's regions probe an HTTP, TCP, DNS, SMTP, or Ping check when you create it, all of them by default, and change the selection later from the check's own settings. A region outside your plan shows in the picker as locked with the tier that includes it, never silently missing. 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 cloud regions on any check it is bound to.

Those are the regions we run from today. We add regions by demand: if the one you need is not in the list, ask for it here and we count the request.

Response assertions

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, the status code falls in a range you pick instead of the default, or a named field in a JSON response holds the value it should. Add them from the check's create or edit form, under "Response assertions."

The JSON assertion addresses one field by path, written the way you would read it in code: data.status, or data.items[0].state for a field inside a list. Require it to equal a value, to contain one, or simply to exist, which is the right choice for a field whose value changes but whose absence means something broke. Paths are plain keys and indexes only: wildcards, filters, and searches through the whole document are not supported, and a path using one is rejected when you save it rather than quietly matching something else.

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.

Response snapshots

When an HTTP check fails, the check's page keeps what came back: the status line, the response headers, and the first 16 KB of the body, for the first failing result of an outage and for the result that recovered. Two per outage per region, not every check, and shown on the incident the outage opened as well. A connection failure or timeout has nothing that came back, so it carries no snapshot.

Before anything is stored, headers named like credentials (authorization, cookie, set-cookie, x-api-key and similar) are replaced with [redacted], and any value that looks like a token, an API key, a card number or a long hash is replaced with [scrubbed]. A snapshot taken while the check was failing is deleted after 30 days; the one taken when it recovered is deleted after 7. Private monitors run by the Monitor agent never capture one. Each check can be opted out from its page. Included on Growth and above.