Skip to content

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.

  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.

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

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

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.

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.

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).

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.

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.

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.

Slow but reachable: the “degraded” status

Section titled “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.