HTTP and keyword monitors

HTTP / HTTPS monitors are the workhorses of Aloft: they request a URL on a schedule and decide whether your site is up based on the response. Keyword monitors go one step further — they also check that a specific string is present (or absent) in the response body.

Both types live under Monitors in the top navigation.

Create an HTTP monitor

1. Go to Monitors and choose New monitor.
2. Give it a Friendly name (for example, “Marketing site”).
3. Set Type to HTTP(s).
4. Pick a check Interval (default: every 5 minutes — see Scheduling and confirmations).
5. Enter the target URL, including the scheme — https://example.com or http://example.com. The URL must use http:// or https://.
6. Optionally set the HTTP method, Expected status codes, and Follow redirects (see below).
7. Choose any alert channels under Alert via.
8. Select Create monitor.

Target URL

Enter the full URL you want checked, path and query included (https://example.com/health?verbose=1). Only http:// and https:// URLs are accepted.

Method

The default method is GET. You can also choose HEAD, POST, PUT, PATCH, or DELETE. For GET and HEAD, no request body is sent.

Expected status codes

A check is considered successful only when the response status code is in the monitor’s expected set. By default Aloft accepts the common success and redirect codes — the 2xx and 3xx families. You can override this with your own comma-separated list (for example 200,204 or 200,301,302). Any code outside the expected set marks the check as down with an “Unexpected status code” message.

Note

Expected status codes must be between 100 and 599, and you can list up to 50 of them.

Custom request headers and body

Under Show advanced options you can add:

• Request headers — one Header: value per line, for example Authorization: Bearer abc123. Useful for hitting authenticated endpoints.
• Request body — sent only for non-GET / non-HEAD methods, for example a JSON payload to a POST health endpoint.

Caution

For your safety, Aloft removes a denylist of headers that could be abused before the request goes out — Host, hop-by-hop headers (Connection, Content-Length, Transfer-Encoding, and similar), and any X-Forwarded-* proxy markers. Authorization is allowed so you can reach protected endpoints. Headers containing line breaks are rejected outright. Probes also refuse to connect to private, loopback, or cloud-metadata addresses.

Follow redirects

Follow redirects is on by default. When enabled, Aloft follows 3xx redirects to the final destination and evaluates that response. Turn it off if you want the monitor to treat the redirect response itself as the result (in which case make sure the redirect code is in your expected status codes).

What counts as up vs. down

For an HTTP monitor the check is up when:

• A response comes back before the timeout, and
• Its status code is in the expected set.

It’s down when the request times out, the connection fails, the target is refused for safety reasons, or the status code falls outside the expected set.

Keyword monitors

A keyword monitor does everything an HTTP monitor does, plus it inspects the response body for a string you specify.

1. Create a monitor as above, but set Type to Keyword.
2. Enter the Keyword — the exact string to look for (for example Welcome or "status":"ok").
3. Choose the Match mode:
   • Should exist — the check passes only if the keyword is found in the body.
   • Should not exist — the check passes only if the keyword is absent.

Matching is a plain substring search (case-sensitive) against the response body, which Aloft reads up to 2 MB.

What makes a keyword check fail

A keyword check is marked down when the keyword condition isn’t met:

• In Should exist mode, the keyword was not found in the body.
• In Should not exist mode, the keyword was present when it shouldn’t be.

The status-code check still applies as well, so a keyword monitor can also go down on an unexpected status code or a timeout.

Tip

Keyword monitors are great for catching “soft” outages — a page that returns 200 OK but is actually showing an error message or a maintenance notice. Watch for a word that only appears when the page is healthy.

Also watch SSL & domain expiry

HTTP and keyword monitors can bundle in two optional expiry sub-checks — the same idea UptimeRobot folds into an HTTP monitor. When creating or editing an HTTP/keyword monitor, look for the Expiry monitoring box:

• Also monitor SSL certificate expiry — opens a TLS handshake to the monitor’s host and reads the certificate’s expiry date. Only runs for https:// URLs.
• Also monitor domain expiry — does a WHOIS lookup on the URL’s registrable domain and reads the registration’s expiry date.

Turning on either toggle reveals Warn me this many days before expiry (default 14, range 1–365) — the shared threshold for both sub-checks.

These sub-checks are warnings only:

• They never change the monitor’s up/down status and never open an incident. A soon-to-expire certificate on a perfectly healthy site keeps the monitor green; you just get a heads-up.
• They run on a roughly twice-a-day cadence (every 12 hours), independent of the monitor’s normal check interval, so WHOIS and TLS endpoints aren’t hammered.
• An alert fires once per expiry date to the monitor’s alert channels. Renew the certificate or domain and the alert re-arms automatically for the next cycle.

The discovered expiry dates appear in an Expiry monitoring card on the monitor’s detail page, with the days remaining highlighted in amber once they fall inside your warning window.

Tip

Prefer a dedicated SSL or domain monitor (see SSL & domain expiry) when you want expiry to drive up/down status and incidents. Use these integrated toggles when you just want a warning bundled onto an existing HTTP check.

Slow but reachable: the “degraded” status

For both HTTP and keyword monitors you can set a response-time threshold (the Degrade above (ms) field under advanced options). When a check succeeds but takes longer than the threshold, Aloft marks it degraded instead of up — the endpoint is working, just slow. Leave the field blank to disable the threshold. See Scheduling and confirmations for more on thresholds and timeouts.