HTTP Endpoints

How to configure HTTP monitoring for websites, APIs, and health check endpoints.

Overview

HTTP monitors send requests to a URL at regular intervals and validate the response. They are the most common monitor type and suitable for checking websites, REST APIs, health check routes, and webhook endpoints.

Configuration

URL and method

Enter the full URL including protocol (https://). MonitorHound supports GET, HEAD, POST, PUT, and DELETE methods.

{
  "url": "https://api.example.com/health",
  "method": "GET"
}

Expected status codes

By default, HTTP monitors accept the following status codes as successful: 200, 201, 202, 204, 301, 302, 304. You can add or remove status codes to match your endpoint — for example, remove redirect codes if you only want to accept 200.

Response body assertions

You can define assertions on the response body using JSONPath expressions. This catches cases where the server returns a success status code but serves unexpected content.

Each assertion consists of:

  • JSONPath expression — The path to the value in the response body (e.g., $.status)
  • Operator — How to compare the value: equals, not_equals, contains, exists, gt, gte, lt, lte
  • Value — The expected value (not required for the exists operator)

You can add multiple assertions per monitor. All assertions must pass for the check to succeed.

Custom headers

Add headers for authenticated endpoints:

{
  "headers": {
    "Authorization": "Bearer eyJhbGciOi...",
    "Accept": "application/json"
  }
}

Request body

For POST and PUT methods, include a request body:

{
  "method": "POST",
  "body": "{\"action\": \"health_check\"}",
  "headers": {
    "Content-Type": "application/json"
  }
}

Check intervals

MonitorHound supports three standard check intervals:

  • 1 minute — Available on Premium and Enterprise plans
  • 2 minutes — Available on Standard, Premium, and Enterprise plans
  • 5 minutes — Available on all plans, including Free (default)

Enterprise plans also support custom intervals beyond these standard options.

Check locations

Checks run simultaneously from up to 5 locations worldwide:

  • US East (South Carolina)
  • US Central (Iowa)
  • Europe West (Belgium)
  • Asia East (Taiwan)
  • Africa South (Johannesburg)

The number of locations available depends on your plan. All selected locations check at the same time, and results are aggregated by the evaluator to determine monitor state.

Check behavior

  1. MonitorHound sends the HTTP request simultaneously from all selected check locations
  2. Response time, status code, and body are recorded at each location
  3. The evaluator aggregates results from all locations
  4. If the monitor transitions to an unhealthy state, alerts are triggered
  5. Response data is stored for historical analysis

Common use cases

  • Website homepage: GET request, expect 200, optional body assertion for page title
  • REST API health check: GET /health, expect 200
  • Authenticated API: GET with Authorization header, expect 200
  • Webhook receiver: POST with test payload, expect 200 or 202