openstatus logoDashboard
docs | reference

HTTP Monitor Reference

An HTTP monitor checks the status of HTTP and HTTPS endpoints. Use it to monitor websites, APIs, webhooks, or any other HTTP-accessible service.

Use cases:

  • Website uptime monitoring
  • API health checks
  • Webhook endpoint validation
  • CDN performance monitoring
  • Authentication endpoint testing

Configuration

URL

Type: String (required)
Format: Full URL including protocol

The URL of the HTTP endpoint you want to monitor.

Examples:

  • https://openstat.us
  • https://api.example.com/health
  • http://internal-service.local:8080/status

Note: We recommend using HTTPS for better security.

Method

Type: String (required) Default: GET

The HTTP method to use when making the request to the endpoint.

Available methods:

  • GET — retrieve data (most common for health checks).
  • POST — send data to create/trigger actions.
  • PUT — update existing resources.
  • DELETE — remove resources.
  • HEAD — like GET but without response body.
  • OPTIONS — query supported methods.
  • PATCH — partial resource updates.
  • TRACE — echo request for debugging.
  • CONNECT — establish a tunnel to the server.

Common usage:

  • Health checks: GET.
  • API testing: POST, PUT, DELETE.
  • Webhook testing: POST.

Body

Type: String (optional)
Available for: POST, PUT, PATCH, DELETE methods

The request body to send with the HTTP request. Supports both text and binary data.

Text body examples:

{ "key": "value" }

Binary data: For binary content (e.g., images), use base64 encoding with data URI:

data:image/jpeg;base64,/9j...

The data URI is only decoded for POST requests that set Content-Type: application/octet-stream. With any other method or content type the string is sent literally.

Content type: Set the appropriate Content-Type header (e.g., application/json, application/octet-stream).

Headers

Type: Key-value pairs (optional)

Custom HTTP headers to include with your request.

Common examples:

Content-Type: application/json
Authorization: Bearer your_token_here
Accept: application/json
User-Agent: Custom-Agent/1.0

Use cases:

  • Authentication — send API tokens or credentials.
  • Content negotiation — specify accepted response formats.
  • Custom identification — add tracking or debugging headers.

Note: openstatus automatically adds User-Agent: OpenStatus/1.0 to all requests. You can override it with a custom User-Agent header.

Up to 20 headers per monitor.

Regions

Type: Array of strings (optional) Default: a plan-based selection (4 regions on the free plan, 6 on paid plans) Format: Region identifiers (e.g., iad, jnb)

The geographical regions from which the HTTP request will be triggered. This allows for monitoring global availability and performance. See the Location Reference for the full list of regions and the IPs to allowlist.

Frequency

Type: String (required) Format: Duration string (e.g., 30s, 1m, 1h)

The interval at which the HTTP monitor will perform checks. Supported frequencies:

  • 30 seconds
  • 1 minute
  • 5 minutes
  • 10 minutes
  • 30 minutes
  • 1 hour

Response time thresholds

Timeout

Type: Duration (optional) Default: 45 seconds

The maximum duration to wait for the HTTP request to complete. If the request exceeds this time, it is considered a failure.

Degraded

Type: Duration (optional)

The duration after which the HTTP request is considered to be performing in a degraded state. This threshold allows for proactive alerting on performance issues before a complete outage.

Retry

Type: Integer (optional) Default: 3

The number of times the monitor will automatically retry the HTTP request upon failure before reporting a definitive error. For example: 3

Follow redirects

Type: Boolean (optional) Default: true

Whether the checker follows HTTP redirects. When enabled, up to 10 redirects are followed and assertions run against the final response. When disabled, the first response is recorded as-is, so a 301/302 is what your status code assertions see.

Assertions

Assertions let you validate specific aspects of the HTTP response. You can define up to 10 status code, 10 body, and 10 header assertions per monitor.

Body assertions

Validate the content of the HTTP response body.

Comparisons:

  • Contains — the response body must include the specified string.
  • Not Contains — the response body must not include the specified string.
  • Equal — the response body must exactly match the specified string.
  • Not Equal — the response body must not exactly match the specified string.
  • Empty — the response body must be empty.
  • Not Empty — the response body must not be empty.
  • Greater Than / Greater Than or Equal — lexicographic comparison against the target.
  • Less Than / Less Than or Equal — lexicographic comparison against the target.

Status code assertions

Validate the HTTP status code of the response.

Comparisons:

  • Equal — the status code must be exactly the specified value.
  • Not Equal — the status code must not be the specified value.
  • Greater Than — the status code must be greater than the specified value.
  • Greater Than or Equal — the status code must be greater than or equal to the specified value.
  • Less Than — the status code must be less than the specified value.
  • Less Than or Equal — the status code must be less than or equal to the specified value.

Header assertions

Validate the presence or content of specific HTTP response headers.

Purpose: verify cache headers, check security headers (e.g., X-Frame-Options), validate content type.

Comparisons:

  • Contains — a header's value must include the specified string.
  • Not Contains — a header's value must not include the specified string.
  • Equal — a header's value must exactly match the specified string.
  • Not Equal — a header's value must not exactly match the specified string.
  • Empty — a header's value must be empty or the header must not be present.
  • Not Empty — a header's value must not be empty.
  • Greater Than / Greater Than or Equal — lexicographic comparison against the target.
  • Less Than / Less Than or Equal — lexicographic comparison against the target.

Example use cases:

  • Verify Cache-Control headers are present and correct.
  • Check for the existence of security-related headers like Strict-Transport-Security.
  • Validate the Content-Type header in API responses.

OpenTelemetry

Configures the export of monitoring metrics to an OpenTelemetry-compatible observability platform.

OTLP endpoint

Type: String (optional) Protocol: HTTP only

The OTLP (OpenTelemetry Protocol) endpoint URL where collected metrics should be exported.

Example: https://otlp.example.com/v1/metrics

OTLP headers

Type: Key-value pairs (optional)

Custom headers to include when sending metrics to your OTLP endpoint. Commonly used for authentication or tenant identification.

Common example:

Authorization: Bearer <your_token>

Public

Type: Boolean Default: false

Controls the visibility of monitor data on your public status page.

  • true — monitor metrics and status are visible to all visitors of your status page.
  • false — monitor data remains private, accessible only within your openstatus dashboard.

Use cases for public visibility:

  • Enhancing transparency with users regarding service health.
  • Providing public API status pages.
  • Displaying SaaS service availability to customers.
Edit this page on GitHubLast updated Jul 27, 2026
PreviousDNS Monitor ReferenceNextIncident Reference