Uptime Monitoring

Know it’s up. Know why when it isn’t.

HTTP checks from the regions you choose, with assertions that go past 200 OK, and the full DNS, TCP, TLS, first byte and download waterfall recorded on every single run.

Included on every plan. Nothing here is an add-on.

One check · as the probe returns it 59.1 ms

$ statuscheck check api.acme.com/health --region fra {  "location": "frankfurt",  "type": "http",  "target": "https://api.acme.com/health",  "up": true,  "status": 200,  "dns": 0.687,  "tcp": 9.433,  "tlsHandshake": 30.141,  "firstByte": 18.313,  "download": 0.11,  "total": 59.059,  "redirects": 0,  "assertion": true,  "sslExpiration": 57,  "sslNotAfter": "2026-10-31T21:41:26Z",  "date": "2026-09-04T12:41:07.617Z"}

timing waterfall, ms assertions region is stamped by the probe, never by the caller

Uptime Monitoring, in detail.

Assertions past 200 OK

Match on status, whether that is an exact code, a 2xx class or a 200 to 299 range. Then add a keyword in the body, a response header, or a regex. Contains, equals and regex operators work on all three.

The whole timing story

DNS, TCP connect, TLS handshake, first byte, and download are timed separately on every check. When a page gets slow, you already know which layer did it.

Requests shaped like your traffic

Custom methods, headers, and bodies. Follow redirects or assert on them. Per-monitor timeouts. Auth headers are stored encrypted and never shown again after you save.

Confirmed before it pages

A failure has to be seen from a second region before the monitor turns down. One region timing out is a data point, not an incident. Single-region monitors say so on the dashboard.

Confirmed before it pages

Monitors / Core platform

Live

API Gateway

https://api.acme.com/health · HTTP · every 60 s

Uptime 30d: 99.98%
p95: 142 ms
Cert: 57 d

24h ago now

Regions · last check

SFO 138 ms
NYC 112 ms
LON 96 ms
FRA 88 ms
SIN 214 ms

Waterfall · FRA 59.1 ms

DNS 0.7
TCP 9.4
TLS 30.1
TTFB 18.3
Download 0.6
Status 200 OK

7,200 checks · 24 h | 0 confirmed failures

Checkout Service is degraded

p95 512 ms over threshold · confirmed from NYC and FRA

#incidents · 12 s ago

The specifics

HTTP monitor options

Written out in full, because “monitoring” means something different at every vendor.

Method: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS
Request: Custom headers, request body, follow-redirects toggle, timeout
Status assertion: Exact code, 2xx class, or an explicit 200–299 range
Body assertion: Keyword or regex: contains, equals, or matches
Header assertion: Any response header: contains, equals, or matches
Interval: 30 s at the fastest, on every plan
Regions: Any of 18, on four continents

Works with

Every part of StatusCheck is on every plan. These are the pieces this one talks to most.

Network Monitoring TCP ports, ICMP reachability, and DNS records SSL Monitoring Certificate expiry, chain completeness, and trust Alerts Nine channels, signed webhooks, and no alert storms

Try it on your own endpoints.

StatusCheck opens in batches. Join the waitlist and we’ll email you once, when it’s your turn. The free plan needs no card.