HTTP Monitor

Periodically sends HTTP requests to websites and API endpoints, verifying the response status code and body.

Use an HTTP monitor when you need to confirm that an application returns the expected HTTP response, not merely that its server accepts a connection.

• Verify the status code of a website or public API
• Detect a content failure that still returns HTTP 200 by checking a keyword
• Check a GET, HEAD, or POST endpoint that does not require a request body

Use a TCP monitor when port reachability is enough, or a Ping monitor for host reachability.

1. Open “New Monitor” from the service detail page and select HTTP.
2. Enter the final URL you actually want to monitor rather than a URL that redirects. HTTP monitors do not follow redirects.
3. Select the method. GET is the usual choice; use HEAD when you only need a response without a body. POST sends no request body, so use it only for endpoints that accept an empty POST.
4. Set the single status code returned during normal operation. The check requires an exact match rather than accepting a range of codes.
5. Add a keyword and presence condition when needed. Do not combine a keyword check with HEAD because HEAD has no response body to inspect.
6. Choose a timeout that covers the normal maximum response time, select an interval allowed by your plan, and create the monitor.

See the Monitor Screens reference for the fields, accepted ranges, and defaults shown in the dashboard.

Method	Use Case
GET	General web page and API checks (default)
HEAD	When you only need the status without the body. Reduces bandwidth
POST	Check an endpoint that accepts an empty POST. No request body is sent

Verify that the response body must contain, or must not contain, a specific string. Even if the status code is healthy, the monitor becomes down when the content violates the selected condition.

For example, this can detect when a maintenance page is served while still returning a 200 status code, indicating the actual content is not being displayed.

Custom headers can be supplied through the Public API, the CLI --config option, or the MCP config object. The dashboard currently has no custom-header input. Header names may only contain alphanumeric characters and hyphens, and values cannot contain line breaks.

The following headers cannot be set for security reasons:

• Host
• Authorization
• Cookie / Set-Cookie
• Transfer-Encoding
• Content-Length

An AbortController stops the request at the configured timeout. The result is down when any of the following occurs:

• A 3xx redirect is returned, even when that same code is configured as the expected status
• The response status code differs from the expected value
• The response does not return within the timeout period
• The response body violates the configured keyword-presence condition
• Connection error (DNS resolution failure, connection refused, etc.)

See Monitoring Lifecycle for when a down result becomes an incident.

Symptom	What to check
A 301 / 302 response is down	Configure the final URL from the Location response instead
HEAD fails when a keyword is configured	Switch to GET when the response body must be inspected
The expected status does not match	Record the one code returned during normal operation, not an authentication or maintenance response
Request timed out	Check normal latency and, if necessary, raise the timeout up to 30 seconds. Prefer a lightweight health endpoint over a long-running operation
The URL cannot be saved	Use a public http:// or https:// URL. localhost, private IPs, and internal hosts are not allowed
An authenticated URL cannot be monitored	Authorization and Cookie headers are blocked. Provide a dedicated health endpoint that does not require secrets
A POST endpoint reports missing input	The monitor sends no request body. Use a separate monitoring endpoint if an empty POST is not accepted