---
title: Web & uptime
description: Monitor websites and HTTP endpoints — status codes, latency with a per-stage breakdown, keyword matching, redirects, HTTP/3 and certificate expiry.
canonical: https://watchfor.io/docs/monitors/web
---

# Web & uptime

Monitor websites and HTTP endpoints — status codes, latency with a per-stage breakdown, keyword matching, redirects, HTTP/3 and certificate expiry.

The **HTTP** monitor is the workhorse: it requests a URL from your chosen
locations on your interval and tells you whether the site answered, how fast,
and whether the response looked right.

**Target:** a full `http://` or `https://` URL.

## What it checks

Every check records:

- **Status code**, and whether it falls in the classes you accept.
- **Response time** with a per-stage breakdown — DNS lookup, TCP connect,
  TLS handshake, time to first byte, download.
- **Body size** and, when a body-match rule is on, whether the body matched.
- **Redirects** — how many, and the final URL (and whether it is HTTPS).
- **Protocol** — the HTTP version used, whether the server advertises
  HTTP/3, and whether the TLS handshake needed a legacy-cipher fallback.
- **Certificate expiry** — days until the certificate expires (HTTPS targets).

## Settings

Under **Settings → Advanced Options**:

| Setting | Notes |
| --- | --- |
| **HTTP Method** | GET (default), POST, PUT, PATCH, DELETE, HEAD or OPTIONS. |
| **Request Body** | Sent with the request; also allowed on GET. |
| **Follow Redirects** | On by default. Turn off to test the redirect itself. |
| **Authentication** | None, Basic, Digest or Bearer token. |
| **Custom Headers** | Any request headers — API keys, `Host` overrides, feature flags. One click adds a **no-cache** bundle (`Cache-Control`, `Pragma`, `Expires`) so the check bypasses CDN caches and tests the origin; expect more load on your backend. |
| **Transport Mode** | **TCP**, **HTTP/3 (forced QUIC)**, or **Auto** (TCP with HTTP/3 fallback). |
| **Network Protocol (IP)** | Auto (prefer IPv4), Force IPv4 or Force IPv6. |
| **Timeout** | Seconds to wait for the response. |

## Alert rules

Presets on the monitor's **Alerting** tab. Two are on for every new HTTP
monitor; the others are one toggle away:

| Preset | Default | Fires when |
| --- | --- | --- |
| **Probe Status** | on | No HTTP response at all — DNS failure, connection refused, TLS error, timeout. |
| **HTTP Status Evaluation** | on | The status is outside the accepted classes. Pick classes (`2xx`, `3xx`, …) or exact codes; the default accepts `2xx` and `3xx`. |
| **Response Time (Latency)** | off | Response time exceeds your threshold in milliseconds. |
| **Response Body Match** | off | The body does — or does not — contain a keyword. Supports exact text, `*` wildcards and regular expressions. |
| **SSL Certificate** | off | Fewer than *N* days remain on the certificate. |

Each rule has a **severity** (critical or warning) and its own
threshold, so a `500` opens *"Unexpected HTTP status"*, a missing keyword
opens *"Body match failed"* and a real outage opens *"Endpoint unreachable"* —
each with its own [root cause](/docs/alerting/root-cause). Failures are
confirmed from other locations before an incident opens; see
[How a failure becomes an incident](/docs/monitors/scheduling#how-a-failure-becomes-an-incident).

The alert metrics for the API are `success`, `status_code`, `response_time`,
`http.body_regexp_match` and `ssl_expiry` — see
[HTTP / HTTPS in the type catalog](/docs/api/monitor-types#http--https).

> **Info**
>
> Need to validate the response *contents* — JSON fields, headers, extracted
> numbers? That is the [API monitor](/docs/monitors/api). For real-browser
> performance (Core Web Vitals, Lighthouse scores) use the
> [Core Web Vitals monitor](/docs/monitors/performance#core-web-vitals-browser).

## Reading the results

The **Overview** shows uptime, a response-time chart (with a logarithmic
scale so a slow outlier doesn't flatten the rest) and a waterfall of where the
time went on each request — a slow TLS handshake looks very different from a
slow origin. The **Probes** tab lists every check per location; **View
response** opens the captured status, headers and body of that check.

## Also via API

Create HTTP monitors with `type: "http"` and the same config keys
(`method`, `followRedirects`, `authType`, `requestHeaders`, `transportMode`,
`failIfBodyMatchesRegexp`, …) — see [Monitors API](/docs/api/monitors) and
the [type catalog](/docs/api/monitor-types#http--https). Try a single request
first with the free [HTTP header checker](/http-header-checker).

---

Canonical page: https://watchfor.io/docs/monitors/web · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt