HTTP Checks

An HTTP Check makes Tickingora send GET to your endpoint at the scheduled times and evaluate the response.

{
  "type": "http",
  "name": "Production API",
  "timezone": "Europe/Warsaw",
  "schedule": { "preset": "custom", "days": [1,2,3,4,5,6,7], "windows": [{ "start": "07:00" }, { "start": "19:00" }] },
  "http": {
    "url": "https://api.example.com/health",
    "expected_status": "2xx",
    "headers": [{ "name": "Authorization", "value": "Bearer status-check-token" }]
  },
  "recovery": { "enabled": true, "interval_minutes": 15 }
}

Target URL

• Only public HTTPS addresses, on port 443 or 8443.
• localhost, private and link-local ranges, cloud metadata endpoints and .local / .internal names are blocked. DNS is checked before every attempt and the connection is pinned to the checked address, so a DNS change cannot redirect a check to an internal host.
• Redirects are not followed: a 301 is a response like any other (useful with expected_status: "301").
• Only the status line and headers are read; the body is never downloaded or stored.

Expected status

Attempts and retries

• Each attempt has a 10 s timeout.
• Up to 3 attempts: the first one plus two retries, 30 s after the previous attempt finished.
• The first response that meets expected_status ends the check with success.
• Timeouts, DNS/TLS/connection errors and wrong status codes are failed attempts. After the third one the check is failed, an incident opens and you get an alert.
• Every attempt is recorded with its status code, duration and error — GET /monitors/{id}/runs returns them in attempts (number, at, http_status, duration_ms, error_type, error).
• If Tickingora itself could not run a check on time, the run is not_executed and nothing is blamed on your service.

Retry settings are fixed in the MVP.

Headers with secrets

Add up to 5 headers (Free plan), e.g. Authorization or X-API-Key.

• Values are encrypted at rest and never returned by the API — responses show { "name": "Authorization", "has_value": true }.
• They are kept out of logs, error messages and e-mails.
• On PATCH, http.headers replaces the list. A header sent without value keeps its stored secret; send a value to replace it; leave a header out to delete it.
• Not allowed (they change transport or routing): Host, Content-Length, Transfer-Encoding, Connection, Keep-Alive, Upgrade, TE, Trailer, Expect, Forwarded, Via, X-Forwarded-*, X-Real-IP, Proxy-*.

# Rotate the check's token, keep the API key header as it is
curl -sS -X PATCH https://dev.tickingora.com/api/v1/monitors/7 \
  -H "Authorization: Bearer $TICKINGORA_API_KEY" -H "Content-Type: application/json" \
  -d '{ "http": { "headers": [
        { "name": "X-API-Key" },
        { "name": "Authorization", "value": "Bearer new-status-token" }
      ] } }'

Use a dedicated token with minimal permissions for status checks.

Recovery checks

With recovery.enabled, after a failure Tickingora also checks every interval_minutes (Free: 15, 30 or 60) — one attempt each — until the service answers correctly. Then the incident closes, a recovery e-mail is sent and the extra checks stop. Regular and recovery checks never hit your endpoint at the same time.

Testing

The dashboard has Test now (also in the wizard before saving). It uses the same URL rules and headers but creates no runs, incidents or statistics.