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 is 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 with component statuses
- Queue depth or replication-lag thresholds
- Feature-flag and version checks
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.