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.

Start free Sign in

Free plan, no card needed.

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.

Browser checks, coming soon

A real browser that loads the page, runs through a flow like sign-in or checkout, and fails when a step does. Not in the app yet. HTTP checks cover the request; browser checks will cover what the user sees.

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

IAD 104 ms
GRU 186 ms
FRA 88 ms
SIN 214 ms
SYD 241 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 IAD 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: 5 min on Free, 60 s on Solo, 30 s on Team and up
Regions: Any of 5, one on each of 5 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 Email, Slack, Teams and six more, with no alert storms

Try it on your own endpoints.

The free plan needs no card. Add a monitor, pick the regions, and see the first check in under a minute.

Start free Sign in