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, 3 minutes, 5 minutes, 15 minutes, 30 minutes, every hour, every 6 hours, every 12 hours, every day. Note that some monitor types have their own slower floor regardless of plan (see Monitor types and their interval floors below).
   • 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). On Free, which shows 14 days of history, the strip has 14 days.
• 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. Resuming needs a free slot under your plan's monitor limit (see below).
• 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. Like any maintenance window, the muted time is left out of the monitor's uptime % (see maintenance windows).
• 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: checks keep running and any incident is still recorded, though the muted time is left out of uptime % just like a pause.

Your plan's monitor limit

Your plan's monitor limit counts running monitors: every monitor that isn't paused. Paused monitors never use a slot, so you can keep more monitors than the limit and choose which of them run.

• Creating a monitor, or resuming a paused one, needs a free slot. At the limit, pause or delete a monitor you need less, then create or resume the one you want — or upgrade.
• If you move to a plan with a lower limit, the newest running monitors over the limit are paused automatically, so the oldest keep running. Monitors you had already paused are left alone and don't count. Nothing is deleted, and the Monitors page lists the monitors paused this way.
• Monitors paused by the plan limit resume automatically, oldest first, once there's room again — for example after an upgrade. A monitor you pause yourself is never resumed automatically.

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.

Interval floors

Your plan sets the fastest interval you can buy (Free 5 minutes, Pro 1 minute, Business and Agency 30 seconds), but each monitor type also has its own floor, and the slower of the two wins. These floors are deliberate: they match how often the underlying data can actually change, and checking a registrar or a certificate authority every 30 seconds would be pure noise for you and unnecessary load on someone else's infrastructure.

So on Business, an uptime monitor can run every 30 seconds while a security-headers monitor on the same site runs every 6 hours. The monitor form only offers the intervals a given type and plan allow, so you can't accidentally select one that would be silently clamped.

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.