JSON health monitoring
Read your health endpoint's JSON, not just its status code.
A JSON health monitor fetches a JSON endpoint and evaluates its content. A struggling subsystem reported in the body gets caught even when HTTP 200 comes back.
How it works
UptimeAlien parses the response and evaluates the top-level status field, recognising the usual names status, state and health. On top of that, sub-checks from a block named checks, services or components are evaluated individually; when no such block exists, the response's flat fields are used instead. Values like ok, up or healthy count as fine, values like fail, error or down as a failure, and degraded as impaired.
When to use it
- /healthz endpoints that report a status per component
- A database or cache connection reported as degraded in the body while HTTP 200 comes back
- Services that express their state as a boolean, such as ok: false or healthy: false
- Endpoints that include a message in error, message or detail on failure; it goes straight into the notification
- A health endpoint that judges queue depth or replication lag itself and reports the result as degraded
- Responses with a block named checks, services, components or dependencies, which the monitor walks through with no configuration
What you get
Overall status, per-sub-check results, response time, uptime and incidents.
Example
marketing.monitoring.types.json.example
Frequently asked questions
What is JSON health monitoring?
It parses the JSON your health endpoint returns and evaluates its status field along with individual sub-checks, instead of only looking at the HTTP status code.
Why isn't HTTP 200 enough for a health endpoint?
Because many health endpoints answer 200 and describe the problem in the body, reporting a degraded database or a failing dependency in a status field. Without reading the JSON, that information is thrown away.
What can I check?
The monitor recognises the common conventions automatically: a status field named status, state or health at the top level, plus sub-checks from a block named checks, services or components. Custom field names cannot currently be configured. If your endpoint doesn't fit that shape, the keyword monitor is the more flexible route.
How does it compare to keyword monitoring?
Keyword monitoring searches the raw response for a string; JSON monitoring parses the structure and checks a specific field. For a machine-readable health endpoint the JSON monitor is the more precise fit.