The Monitors view combines two related surfaces: Uptime checks (outside-in HTTP/HTTPS probing) and Heartbeats (services phoning home). Both live behind the same sidebar entry so you can see at a glance how many public endpoints and background jobs are healthy.

Open it from the sidebar under Monitoring → Monitors. The URL is /uptime, with a Uptime and a Heartbeats tab at the top.

What you see

The header carries KPI cards for both tabs:

• Uptime tab — total checks, up, degraded, down.
• Heartbeats tab — total heartbeats, healthy, missed / failed.

The Uptime table lists every external URL monitor: name, URL, method, current status, 24 h uptime %, average response time, interval, and last check. Down and degraded rows are highlighted.

Note

Uptime checks tied to a discovered domain do not show up on this page — they live on the domain detail page as sub-checks, one for the root URL plus any additional paths (e.g. /api/health, /login) you add. The standalone list only shows monitors created without a linked domain.

Click a row to open the check detail. It shows:

• Uptime rollups for 24 h, 7 d, and 30 d.
• Average response time.
• A response-time chart with one line per probe location.
• A per-probe result log with response time, HTTP status, SSL validity, and any error message.

What you can do

From the tab header:

• New monitor — opens the create form for a URL monitor.
• New heartbeat (Heartbeats tab) — jumps to the heartbeat create form (see Heartbeats).

For an existing URL monitor you can:

• Edit — name, URL, method, interval, timeout, expected HTTP status, SSL validation on/off.
• Delete — removes the monitor and its history.
• Pause via linked domain — if the check belongs to a domain, toggling monitoring on the domain pauses this check with it (no alerts during the pause).

Creating a URL monitor

The create form asks for:

Field	Notes
Name	Free-form label used in alerts and the list.
Check type	Uptime (simple HTTP GET/HEAD) or API (POST/PUT/PATCH/DELETE with headers + body).
URL	Full http:// or https:// URL, up to 500 characters.
Method	GET, HEAD, POST, PUT, PATCH, DELETE.
Interval	Between 60 s and 3600 s (one minute to one hour).
Timeout	5–60 seconds. A probe that runs past the timeout counts as down.
Expected status	Any HTTP status code from 100 to 599. Anything else is down.
Expected content	Optional substring, negation, regex, or JSON-path check on the response body.
Headers	Optional, one Key: Value per line — useful for API auth.
Body	Optional request body for non-GET methods.
SSL check	When enabled, an invalid or expired certificate marks the check degraded even if the HTTP status is fine.

How it works

Every URL monitor is run by HostAtlas’ distributed probe network — small worker nodes deployed in several regions. Each probe hits your URL on its own schedule, records the HTTP status, response time, and SSL validity, and stores the result.

• A check is up when every active probe gets the expected status within the timeout.
• A check is degraded when some probes succeed and others fail, or SSL validation fails while HTTP is fine.
• A check is down when every probe fails.

The status is refreshed after every probe run, and the 24 h / 7 d / 30 d rollups are pre-aggregated so the list stays fast even with hundreds of monitors.

Notifications

Uptime alerts flow through the normal Alert Rules engine — pick a Slack, email, webhook, PagerDuty, or SMS channel there and target Uptime as the source. During a Maintenance Window uptime alerts are suppressed automatically.

Plan gates

Every plan includes a set number of URL monitors. When the cap is reached, the create form redirects to /billing with a toast. See the Billing page for your current usage.

Related

• Heartbeats — the other half of the Monitors umbrella.
• Domains — where per-domain uptime sub-checks live.
• SSL Certs — for certificate-only monitoring.
• Alerts — route uptime events to notification channels.