What it is
When a site or API goes down, every minute before you notice is downtime your users feel and you don’t. An HTTP probe closes that gap. It requests a URL on a fixed schedule and records whether it responded the way you expect, so an outage reaches you from a probe instead of from a customer. It’s the probe to reach for with anything that speaks HTTP or HTTPS: a marketing site, a web app, a REST API, or a dedicated health-check endpoint.
By default the probe is up whenever the URL returns a 2xx status code, and down
otherwise. It also captures the response time and the phase timings underneath it
(DNS, TCP connect, TLS handshake, and time to first byte), so a slow response tells
you where the time went.
When to use it
Reach for an HTTP probe when
- You’re watching a website or landing page and want to know the moment it stops serving.
- You have an API or health endpoint (say
/healthz) that returns200when the service is healthy. - You care about response latency, not just reachability.
- The check needs to validate HTTPS, follow redirects, or send a specific method.
Use a different probe when
- The thing you’re watching doesn’t speak HTTP, like a database, mail server, SSH, or a game server. A TCP probe fits that better.
- You want warning before your domain registration lapses. That’s the Domain probe.
How it works
Uptimeprobe requests the URL on your interval, follows redirects, and verifies the TLS certificate. It records the status code, the response time and its phases, and any error, then works out the probe’s status from your recent checks. A single check is equivalent to:
curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" \
https://api.example.com/health
200 0.148sConfiguring an HTTP probe
Create one from Probes, then Add probe, and pick HTTP.
| Field | What it does | Notes |
|---|---|---|
| Name | A label for the probe | Required, 1 to 255 characters |
| URL | The address to request | Starts with http:// or https://, up to 2048 characters |
| Method | The HTTP method to send | GET, HEAD, or POST |
| Interval | How often to check | 30s, 1m, or 5m |
Every HTTP probe follows redirects, verifies TLS certificates, and uses a 10-second
request timeout. A 2xx response inside that window counts as up.
Choosing an interval
Faster intervals catch outages sooner and cost more checks. 1m suits most sites and
APIs. Drop to 30s for endpoints where seconds matter, or 5m for low-traffic pages
where a slightly slower alert is fine.
How status is determined
Status comes from your recent checks:
- Down: several checks in a row have failed (a non-
2xxstatus, a timeout, or a connection, TLS, or DNS error). - Degraded: recent checks are intermittently failing, or responses are running slow.
- Up: recent checks are succeeding and responsive.
- No data: no recent check has reported, so status is unknown.
Next steps
Want to watch your first endpoint? Create an account and add an HTTP probe in about a minute. Monitoring something that isn’t a web endpoint? See the TCP and Domain probes.