Monitor types

Uptime Cloud has five monitor types. You pick the type when you create a monitor.

1. HTTP monitor

The standard website/endpoint check. Uptime Cloud sends an HTTP request to your URL and considers it up if the response status code matches what you expect (200 by default). Use this for websites, web apps, and simple health endpoints.

2. Keyword monitor

Everything an HTTP monitor does, plus it inspects the response body for a word or phrase. You choose the match rule:

• Contains — the monitor is up only if the keyword is present (e.g. the word “Welcome” appears, proving the page actually rendered).
• Does not contain — the monitor is up only if the keyword is absent (e.g. the word “Error” or “Database connection failed” is not on the page).

This catches “soft” outages where a server returns a 200 status but the page is actually broken.

3. API monitor

For JSON APIs. It sends a request and then runs assertions against the JSON response body — so you can verify not just that the API responded, but that it responded correctly.

Each assertion targets a field using a simple JSONPath-style path (e.g. $.data.status or $.items[0].id) and a comparison:

• equals, not_equals
• contains, not_contains
• greater_than, less_than
• exists, not_exists

You can add multiple assertions and choose whether all must pass or any one passing is enough. Example: assert that $.status equals "ok" and $.queue_depth is less than 100.

4. Port monitor

A TCP reachability check. Uptime Cloud opens a TCP connection to a host and port (e.g. a database on :5432, an SMTP server on :25, a game server, etc.). If the connection is accepted, the service is up; the connect time is recorded as the response time. Use this for non-HTTP services.

Note

This is a TCP check, not an ICMP “ping.” (Ping/ICMP isn’t available on the underlying platform, so port checks are the reachability probe.)

5. Heartbeat monitor

An inbound monitor — the reverse of the others. Instead of Uptime Cloud reaching out to you, your job pings Uptime Cloud. You get a unique ping URL; your cron job, backup script, or scheduled task hits that URL every time it runs successfully. If a ping doesn’t arrive within the expected window, the monitor goes down and alerts you.

Use this for things that have no public endpoint: nightly backups, data pipelines, cron jobs, scheduled reports.

Configuration:

• Expected interval — how often the ping should arrive (from 60 seconds up to 30 days).
• Grace period — extra slack before it’s considered overdue (from 10 seconds up to 1 day).

If a ping is late beyond interval + grace, the heartbeat is marked down with a cause like “No ping received for N minutes.”