Uptime

Product / Monitoring

Check the layer
that matters.

A website, an API, a port, or a certificate. Get the right signal from independent regions, with clear evidence behind every result.

Start monitoring for freeExplore check types

10 monitors free No credit card required

Independent regionsEvidence with every check
Acme Cloud/MonitorsExample monitor

Checkout API

checkout.acme.dev/health

HTTP
Explore a check
Response
200OK
Response time
184ms
Check location
VirginiaUS East
Response time · Virginia1-minute interval

All 36 recent checks passed.

A healthy response, verified.

HTTP 200 matches the expected 2xx–3xx policy.
3 probe regionsInspect the evidence
Illustrative data · One-minute Pro checks

01 / Choose your signal

Every layer.
A meaningful check.

Start with what your customers use. Then check the connections, records, and certificates that keep it working.

Compare monitor types
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
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
New to monitoring? Start with an HTTP check for your public website.Create your first monitor

02 / Confirm the signal

A failed check
starts a question.
Evidence answers it.

Require repeated failures across independent regions before a temporary network problem becomes an outage alert.

  1. 01

    Check again.

    Use consecutive failures to separate a brief interruption from a persistent problem.

  2. 02

    Compare regions.

    Decide how many locations need to agree before confirming an incident.

  3. 03

    Bring in the team.

    Send an alert with the regional evidence that explains why it was triggered.

Choose a regional strategy

Regional confirmation network

Checkout API · Illustrative Pro checks

Compare example signals

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.

03 / Follow the evidence

The result is just
the beginning.

See what each region observed, why the check failed, and the incident it produced. Give your next decision a clear starting point.

Explore this incident
Checkout API / Check evidenceIllustrative data · All times UTC
Regional observations09:42:12 UTC

Virginia

US East
503UnavailableFailed twice

Frankfurt

Europe
503UnavailableFailed twice

Oregon

US West
200OKPassed twice
Two consecutive checks, one minute apart.
Outage confirmed
2of 3 regions

The confirmation rule is met.

Virginia and Frankfurt fail twice. Oregon remains reachable. The incident keeps that distinction visible.

2 failures per region 2 regions
Open example incident

04 / Make it your own

Your service.
Your definition of healthy.

Decide what success looks like, when your team should hear about a failure, and how planned work fits into the picture.

01

Define a meaningful failure.

Configure response assertions and thresholds so a successful connection is only the beginning.

Response assertionsStatus · Content · DNS
Choose your monitor
02

Control when alerts leave.

Tune notification policies and event preferences around the people responding to an incident.

Notification policyOutage · Recovery
Explore alert policies
03

Account for planned work.

Keep scheduled downtime distinct from unexpected service failures with maintenance windows.

Maintenance windowsScheduled · Scoped
Plan maintenance

Start with one service

Make your next check count.

10 monitors. Five-minute checks. A clearer picture of reliability.

Start monitoring for freeCompare plans