HTTP
HTTP and HTTPS
Exercise a public URL with GET, HEAD, POST, PUT, or PATCH and evaluate its response—not only whether a socket opened.
- Status policy
- Headers and body
- Redirect control
Monitoring / Built for the details
Check the layer
that matters.
A website, an API, a port, or a certificate. Monitor the right signal from independent regions, with clear evidence behind every result.
10 monitors · Five-minute checks on Free · No credit card
HTTP monitorIllustrative configuration
Example service
Checkout API
GETcheckout.acme.dev/health
- Check interval
- Every minute
- Probe regions
- Virginia, Frankfurt, Oregon
- Failure threshold
- 2 consecutive failures
- Regional agreement
- 2 of 3 regions
A first failed check starts an investigation. Repeated regional failures confirm the outage.
Choose your signal
Go beyond “is it up?”
Match each check to what your service needs to do. Combine protocols to see where a failure starts.
TCP
TCP port
Confirm that a public host accepts a connection on the exact port your service depends on, from every selected region.
- Ports 1–65535
- Connection latency
- Refusal evidence
ICMP
ICMP ping
Measure basic network reachability for infrastructure that intentionally answers ICMP. Use HTTP or TCP when ping is blocked.
- Explicit opt-in
- Round-trip latency
- Timeout evidence
DNS
DNS resolution
Resolve public records through the system resolver or a selected nameserver and optionally require an expected answer.
- 10 record types
- Custom nameserver
- Answer assertion
TLS
SSL and TLS
Inspect HTTPS certificates for expiry, hostname mismatch, trust, chain integrity, and self-signed certificate conditions.
- 30-day warning
- Chain metadata
- Expiry alerts
Find the right check.
Start with the service your customers use, then add checks for the dependencies behind it.
Compare monitor typesIndependent regions, shared evidence
Confirm the outage.
Filter the temporary failure.
Define how many regions must fail, and how often, before your team receives an outage alert. Compare both outcomes in this example.
Regional confirmation network
Checkout API · Illustrative Pro checks
Fictional data · Checks one minute apart · Two consecutive failures in two regions required.
Virginia
- First check
- 503
- Next check
- 503
Frankfurt
- First check
- 503
- Next check
- 503
Oregon
- First check
- 200
- Next check
- 200
Shared confirmation rule
2 of 3 regions confirm the outage
Virginia and Frankfurt fail twice. The outage is confirmed and the team receives Email and Slack alerts.
HTTP 200 = successful response · HTTP 503 = service unavailable. The team can publish a customer update on the connected status page.
The result, with its context
Less guessing.
More evidence.
Inspect regional responses and follow the incident they produced. Check results help distinguish a service failure from a single troubled network path.
Explore this incidentCheckout API / Regional evidence
Example checks · UTCVirginiaHTTP 503 / Failed twice
FrankfurtHTTP 503 / Failed twice
OregonHTTP 200 / Passed
09:42:12 · Outage confirmed
Virginia and Frankfurt meet the repeated-failure threshold. Oregon remains reachable.
Monitoring that fits your operation
You set the rules.
Define a meaningful failure.
Configure response assertions and thresholds so a successful connection is only the beginning.
Choose your monitorControl when alerts leave.
Tune notification policies and event preferences around the people responding to an incident.
Explore alert policiesAccount for planned work.
Use maintenance windows to keep scheduled downtime distinct from unexpected service failures.
Plan maintenanceStart with one service
Make your next check count.
Create a free workspace and start building a clearer picture of reliability.