HTTP & keyword monitors

A website monitor (Website (is the page up?) in the type list) requests a URL from each of your check locations and decides whether the response is healthy. Out of the box it checks that the site answers with the expected status code. You can add keyword checks, header rules, response-time limits and more under Show advanced options.

API monitors use the same request and validation settings, plus a request body and assertions. They are covered in API & multi-step checks. Everything on this page applies to them too.

Create an HTTP monitor#

1. Go to Monitors → New monitor.
2. Keep What do you want to check? set to Website (is the page up?).
3. Enter the URL, for example https://example.com/health, and optionally a Name. A blank name becomes the host name.
4. Choose a Check interval.
5. Optionally click Show advanced options to add keyword checks, headers or limits.
6. Click Test to try it, then Create monitor.

SutramX also looks at the page once and can suggest related checks, such as the checkout or login page. Nothing is added unless you tick it. See Site detection and suggested checks.

If you type a bare host name such as example.com, the dashboard adds https://. The scheme and host are lower-cased; the path and query string keep their case.

Guided presets#

The Guided preset list fills in sensible advanced settings in one click. It appears in the Add new monitor dialog when you choose API endpoint. The dialog lists exactly what it changed.

You can change any value after applying a preset.

Request settings#

Headers you can't set. Host, Content-Length, Transfer-Encoding, Connection, Upgrade, Proxy-Authorization and Proxy-Connection are controlled by SutramX and are dropped if you add them.

Headers on redirects. When a redirect leads to a different scheme, host or port, SutramX only forwards User-Agent, Accept, Accept-Language and Accept-Encoding. Your auth and custom headers are dropped so a secret never reaches another site. A redirect from HTTPS to plain HTTP is refused when you send custom headers.

Default request headers#

Unless you set your own, every check sends:

User-Agent: Mozilla/5.0 (compatible; SutramX-Monitor/1.0; +https://sutramx.com/bot)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.9

Adding a header with the same name (in any letter case) replaces the default.

Validation settings#

A response must pass every rule you set. They are checked in this order, and the first failure is what you see in the check history and alerts.

Keywords are matched against the raw response body, including HTML markup. A HEAD request has no body, so don't combine HEAD with keyword checks.

The status code checked is the one from the final response, after redirects are followed.

Alert thresholds#

Under Detection in the same advanced options:

These work together with multi-location confirmation. See Regions & confirmation.

Choose which errors alert#

In the monitor editor (Edit), expand Alert on these HTTP errors. Every failure has an error class, such as Status 5xx, Timeout Connect or Keyword Not Found. Untick a class to stop it from sending notifications. The check is still recorded as failed; it just doesn't notify anyone. Use Select all or None to change them all.

Error types#

Each failure is tagged with one error class. The editor shows them in readable form (for example timeout_connect appears as Timeout Connect); the API uses the ids below.

Bot protection and firewalls#

Firewalls and bot filters (Cloudflare, Vercel, AWS WAF, Akamai, Imperva, Sucuri, DataDome, Kasada and similar) sometimes block monitoring traffic. When that happens the site may be perfectly healthy, but the check can't tell.

SutramX recognises these blocks instead of reporting them as an outage. A response with status 403, 429 or 503 that carries a vendor-specific header or a vendor's block-page text is classified as Blocked by bot protection (WAF), with a message like:

Blocked by Cloudflare bot protection (HTTP 403) — the target refused the check, so its availability could not be verified. Allowlist the checker in the target's firewall: https://sutramx.com/bot

Detection is deliberately conservative. A plain 403 from a site behind Cloudflare is still reported as a normal 403, because many APIs return real 403s. A 401 is never treated as a block. A plain 429 without a vendor marker is reported as Rate limited (HTTP 429) instead. Neither a block nor a rate limit counts as downtime. If you set expected status codes that include the blocking status, the check passes.

To fix a block:

1. Allowlist SutramX in your firewall. The user agent and checker IP addresses are listed at https://sutramx.com/bot.
2. Or add a secret request header (for example X-Monitor-Token) under Request headers and allow requests that carry it.
3. If you'd rather not be notified about blocks, untick Blocked by bot protection (WAF) under Alert on these HTTP errors.

Example: create through the API#

The API takes the same settings in config. Times are in milliseconds and sizes in bytes.

curl -X POST "https://api.sutramx.com/monitors" \
  -H "Authorization: Bearer sk_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Checkout page",
    "type": "http",
    "url": "https://shop.example.com/checkout",
    "interval_seconds": 60,
    "config": {
      "method": "GET",
      "headers": { "X-Monitor-Token": "s3cret" },
      "expected_status_codes": [200],
      "keyword": "Place order",
      "keyword_case_insensitive": true,
      "forbidden_keywords": ["Internal Server Error"],
      "expected_response_headers": [{ "name": "content-type", "value": "text/html" }],
      "timeout": 15000,
      "max_redirects": 3,
      "max_response_bytes": 1048576,
      "max_response_time_ms": 3000,
      "degraded_response_time_ms": 1500,
      "failure_threshold": 2,
      "recovery_threshold": 1,
      "verify_tls": true
    }
  }'

The whole config object can have at most 50 keys and 32 KB when serialized.

Troubleshooting#

The check times out but the site loads in my browser. The response time includes DNS, connecting, TLS, redirects and downloading the full body. Raise Timeout, and remember it is capped at the interval minus 3 s. The error message shows the timeout actually used.

"Response body is larger than the … byte limit, so keyword/body checks could not run". The page is bigger than Max response size and a keyword or body rule needs the whole page. Raise the size (up to 10 MB), remove the body rule, or check a lighter health endpoint.

Keyword not found, but I can see the text on the page. The keyword is matched against the HTML the server returns, not what JavaScript renders afterwards, and it is case-sensitive unless Ignore letter case is on. HTML entities (such as &) are not decoded.

A 301 or 302 fails my check. Redirects are followed by default, so you normally see the final status. If Max redirects is 0, the redirect itself fails the check. Add the redirect status to Expected status codes if you want to monitor the redirect.

Self-signed or internal certificates. Untick Fail if the HTTPS certificate is invalid or expired. The host still has to be publicly reachable.

"Target resolves to a non-public address". SutramX only checks public hosts. Private IPs, localhost and internal names can't be monitored.