HTTP uptime monitors

An Uptime (HTTP) monitor fetches a URL on a schedule, records the status code, total response time and time-to-first-byte, and opens an incident when the site is confirmed down.

Create an uptime monitor

1. Go to /monitors and click to create a monitor (or open /monitors/create directly).
2. Fill in the shared fields:
   • Project — which project the monitor belongs to.
   • Name — a label, e.g. "Marketing site".
   • Type — choose Uptime (HTTP). The type is fixed after creation; to switch types, create a new monitor.
   • Target — the full URL, starting with http:// or https://.
   • Check interval — one of: every 30 seconds (Business and Agency), 1 minute, 5 minutes, 15 minutes, 30 minutes, every hour, every 6 hours, every day.
   • Ownership attestation — tick "I'm authorized to monitor this target." CompleteStatus stores who attested and when.
3. Fill in the uptime-specific fields (below) and save. The first check runs on the next scheduler tick.

Interval limits per plan

Your plan sets the fastest allowed interval: Free — 5 minutes (so faster options like 1 minute are rejected; pick 5 minutes or slower), Pro — 1 minute, Business and Agency — 30 seconds. Choosing an interval faster than your plan allows shows an inline validation error with the minimum.

Uptime-specific fields

• Expected status (default 200-399) — the status codes treated as healthy. By default any 2xx or 3xx response counts as up; anything else (4xx, 5xx) fails the check with "Unexpected HTTP status". For guidance on which codes should page you, see HTTP status codes through a monitoring lens.
• HTTP method — GET or HEAD. Use HEAD when you don't need the body (note that keyword checks need a body, so use GET with keywords).
• Keyword (optional) — a literal string the response body must contain. The toggle "Keyword must be present" flips the assertion: unchecked, the check fails when the keyword appears (useful for catching error text like "database error" on a page that returns 200).

Note: For richer content matching (regex, case sensitivity) there is a dedicated Keyword monitor type, and for structured API responses see API monitors and assertions.

How a check runs

• Each check is time-boxed to 30 seconds in total.
• A network/connection error is retried once within the same check before it counts as a failure.
• Redirects are followed, up to 5 hops; more than 5 fails the check. The redirect chain and final URL are recorded on the result.
• Every URL — including every redirect hop — is validated against private and internal network ranges before it is fetched. Targets that resolve to internal addresses are rejected.
• Checks currently run from a single probe region.

Each result stores: ok/fail, HTTP status, latency (ms), time-to-first-byte (ms), and a detail record (error message, keyword match, redirect chain).

What "confirmed down" means

CompleteStatus never opens an incident on a single failed check. The status state machine requires 2 consecutive failures to confirm DOWN:

So with a 5-minute interval, a real outage is confirmed and alerted within roughly two check cycles. Paused and maintenance states are user-controlled: results may still be recorded, but the status never transitions and no incidents open.

Incidents appear on the monitor page and the dashboard, with a cause (e.g. HTTP 503 or the connection error) and a timeline of events.

The monitor detail page

Open any monitor from /monitors to see:

• Current status, 24h uptime percentage, and the p95 latency for the selected range (24h / 7d / 30d).
• A latency chart and a 90-day uptime heat strip (green ≥ 99%, yellow ≥ 90%, red below).
• The last 50 checks and the last 25 incidents.
• The Alert rules panel for routing events to your channels.

Managing a monitor

All actions are on the monitor list and detail pages:

• Pause / Resume — pausing stops scheduling entirely and sets the status to Paused. Resuming sets it back to Pending and queues a check immediately.
• Check now — queues an immediate check without waiting for the schedule.
• Mute — silences alerts for this monitor for a preset duration (30, 60 or 120 minutes) by creating an ad-hoc maintenance window. Unlike pause, checks keep running and results keep recording; you just aren't notified.
• Edit — change the project, name, target, interval and type-specific settings. The type itself is immutable.
• Delete — removes the monitor and stops all checks.

Warning: Pausing a monitor means outages during the pause are simply not observed. If you only want quiet during a deploy, use Mute or a maintenance window instead.

Monitor a whole site in one go

Instead of adding checks one at a time, /monitors/site takes a single domain and creates a properly-configured monitor per selected check: Uptime (every 5 minutes), SSL/TLS certificate, security headers, DNS, domain expiry, email security (SPF/DKIM/DMARC) — all pre-ticked — plus optional page health. If your plan's monitor cap doesn't fit all selections, CompleteStatus creates the most important ones first and tells you what was skipped.

Related guides

• Getting started — alert channels and the dashboard.
• Cron and heartbeat monitors — for jobs that can't be probed from outside.
• SSL, DNS and domain monitors — the security-facing check types.
• Uptime monitoring best practices — intervals, false positives and what 99.9% actually means, on the blog.