Monitoring

HTTP Checks

Set up HTTP monitoring in Alert24 to check your APIs and websites for uptime, response codes, SSL certificates, keyword matching, and JSON response assertions.

What are HTTP Checks?

HTTP checks are the primary way to monitor your own services in Alert24. They send HTTP requests to your endpoints at regular intervals and verify the response is what you expect.

Checks run from 15 global locations across 6 continents — Virginia, Washington, Des Moines, Toronto, Amsterdam, Frankfurt, London, Paris, Singapore, Tokyo, Seoul, Pune, Sydney, Sao Paulo, and Johannesburg. By default, checks round-robin through all locations automatically, giving you geographic diversity without any configuration. You can also select specific cities to check from.

If something goes wrong — the server doesn't respond, returns an error code, or the response doesn't contain expected content — Alert24 detects it and alerts you.

Setting Up an HTTP Check

  1. Navigate to Monitoring in the navigation bar
  2. Click Add Check
  3. Select HTTP Check
  4. Configure the check (see options below)
  5. Link it to a service
  6. Click Create

[Screenshot: HTTP check configuration]

Configuration Options

URL

The endpoint to monitor. This can be any URL that returns an HTTP response:

  • https://api.yourapp.com/health
  • https://www.yoursite.com
  • https://api.yourapp.com/api/v1/status

Use HTTPS whenever possible. Alert24 follows redirects by default.

HTTP Method

The HTTP method to use for the request:

  • GET — Most common for health checks and website monitoring
  • POST — Useful for API endpoints that require POST
  • HEAD — Lighter weight, only checks if the endpoint responds

Expected Status Code

The HTTP status code you expect the endpoint to return. Common values:

  • 200 — Standard success response
  • 201 — Created (common for POST endpoints)
  • 204 — No content (common for health checks)
  • 301/302 — Redirect (if you expect the URL to redirect)

If the actual status code doesn't match the expected code, the check fails.

Check Interval

How often Alert24 sends a request to your endpoint:

  • 30 seconds — For critical services that need near-instant detection
  • 60 seconds — Good balance of speed and resource usage (recommended)
  • 300 seconds (5 minutes) — For less critical services

Timeout

How long to wait for a response before marking the check as failed:

  • 5 seconds — Strict, good for fast APIs
  • 10 seconds — Reasonable default
  • 30 seconds — For slower endpoints or services with cold starts

Keyword Matching

Optionally verify the response body against a string. Choose a match type:

  • Contains — The response must include this text (e.g., "status":"ok")
  • Exact — The entire response body must equal this text
  • Regular expression — The response must match this regex pattern

Keyword matching catches issues where the server returns a 200 status code but the response body indicates an error — a common problem with API health checks.

JSON Assertions

For JSON APIs and health endpoints, assert on a specific field in the response instead of matching raw text. This is the most precise way to validate a health check: a server can return 200 OK while a critical dependency is down, and a JSON assertion catches that.

Configure two values:

  • JSON Path — Dot-notation path to the field, with an optional leading $. Supports nested keys and array indices:
    • $.status
    • $.checks.database
    • $.checks[0].ok
  • Expected Value — What the field should equal. Values are coerced, so true/false, numbers, and "null" compare correctly (e.g. expected ok matches the string "ok", expected 200 matches the number 200). You can also use special keywords:
    • exists — the field is present and non-null
    • not_exists — the field is absent or null
    • truthy — the field is a truthy value
    • falsy — the field is a falsy value

Example. For a health endpoint returning {"status":"ok","checks":[…]}, set JSON Path $.status and Expected Value ok. The check fails if status is anything other than "ok", even on an HTTP 200.

Auto-detect

Click Auto-detect from URL and Alert24 fetches the endpoint, parses the JSON, and suggests assertions for any standard health fields it finds (status, ok, healthy, and similar). Click a suggestion to apply it — no need to write the path by hand.

Test Check

Before saving, click Test Check to run the check once immediately. The test validates everything you've configured — status code, keyword match, and JSON assertion — and reports the result, including the specific reason if an assertion fails (e.g. "JSON path $.status did not match expected value 'ok'"). Use it to confirm your assertion is correct against the live response before the check goes into rotation.

SSL Certificate Verification

When enabled, Alert24 verifies that the SSL certificate is valid and not expired. You can also configure alerts for certificates expiring within a certain number of days (e.g., 14 days before expiration).

Request Headers

Add custom headers to the request if your endpoint requires authentication or specific headers:

Authorization: Bearer your-token
Accept: application/json
X-Custom-Header: value

Understanding Check Results

Each check result includes:

  • Status — Pass or fail
  • Response time — How long the request took in milliseconds
  • Status code — The HTTP status code returned
  • Timestamp — When the check ran

Real-Time vs. Historical Data

Alert24 runs checks at the interval you configure (from 30 seconds to 10 minutes depending on your plan), so the status displayed on your status pages is always up to date. When a check detects an issue, your status page updates and alerts go out immediately.

For historical data, Alert24 stores check results at 5-minute intervals. This means uptime history charts and reports reflect 5-minute granularity, while live status is always current.

Alerting

When an HTTP check fails and meets the failure threshold (configured in Check Configuration), Alert24:

  1. Updates the linked service status
  2. Sends alerts via your configured notification channels
  3. Displays the issue on your status page (if the service is listed)

Best Practices

  • Monitor your health endpoint, not just your homepage — health endpoints are designed to verify all critical subsystems
  • Assert on the response body, not just the status code — use a JSON assertion ($.status = ok) or keyword match to catch silent failures where the server returns 200 but a dependency is down
  • Use Test Check before saving to confirm your assertion matches the live response
  • Set appropriate timeouts — don't set a 5-second timeout for an endpoint that legitimately takes 8 seconds
  • Monitor from the customer's perspective — check the URLs your customers actually use
  • Include SSL monitoring for all production HTTPS endpoints
Previous
Service Status
Next
Status Page Checks