Monitoring

HTTP Checks

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.

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 that the response body contains (or doesn't contain) a specific string:

  • Contains keyword — The response must include this text (e.g., "status":"ok")
  • Does not contain keyword — The response must NOT include this text (e.g., "error")

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.

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

Alert24 stores check history so you can review trends and identify intermittent issues.

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
  • Use keyword matching to catch silent failures where the server returns 200 but the response is wrong
  • 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
← Service StatusStatus Page Checks →