Custom Data Monitoring (JSON/XML)

A 200 OK only proves the server answered. It says nothing about what it answered with. Custom data monitoring closes that gap: instead of trusting the status code, you monitor a JSON endpoint (or XML) by reading an actual value out of the response body and alerting when that number drifts where it shouldn't. Queue depth, active users, error count, cache hit ratio, a business figure — if your app can expose it on a URL, you can chart it and set a trigger on it. This page walks through what it is, how the parsing works, how to set it up, and where it fits.

What is Custom Data Monitoring (JSON/XML)

Custom data monitoring is availability monitoring that looks inside the response. Rather than stopping at "did the endpoint reply," it parses the returned JSON or XML, extracts a numeric field, records it over time, and fires an alert when the value crosses a threshold you set. It turns any HTTP endpoint into a metrics source without you standing up a full observability stack.

You reach for this when a status code isn't enough. Plenty of failures return a perfectly cheerful 200 while the payload tells a grimmer story — a job queue backing up, a replication lag climbing, a "healthy: false" buried in an otherwise fine response, a stale timestamp that means the data hasn't refreshed in hours. To monitor a JSON endpoint this way, you expose the number you care about as a first-level field, point the monitor at the URL, and tell it which key to watch. From then on that value is tracked and alertable exactly like response time or uptime — except it's your metric, specific to what your service actually does.

How it works

The monitor requests your endpoint on a schedule, just like an availability check. The difference is what happens next: instead of only reading the status code, it parses the response body as JSON or XML and pulls out the first-level numeric fields. Each of those becomes a data series you can graph, and each can carry its own alert trigger. When a parsed value moves outside the range you defined, the alert fires — over the same real-time email and SMS channels as any other check.

The key constraint is first-level. The parser reads top-level numeric fields; it doesn't dig through deeply nested objects or arrays. So the practical rule is to surface what you want watched at the root of the payload.

This is why designing the endpoint matters as much as configuring the monitor. Keep the numbers you care about flat and clearly named. And as with every check here, the parsing happens on the external side — the monitor pulls your endpoint from outside your network, so a value that signals trouble still gets read even when the host is under strain, which is the double durability idea carried into your own application metrics.

Setup

To monitor a JSON endpoint with custom data checks, follow this order:

1. Expose the metric. Add or identify an endpoint that returns your value as a first-level numeric field — {"active_users": 1280, "queue_depth": 42} is ideal. Flat and named, not buried.
2. Return the right content type. Serve valid application/json or application/xml so the parser reads it cleanly.
3. Register the endpoint. Point the monitor at the URL and let it fetch a sample so it can discover the available first-level fields.
4. Pick the field and range. Choose which parsed value to watch and set the trigger — an upper bound on queue depth, a lower bound on active users, whatever "abnormal" means for that number.
5. Set frequency and alerts. Choose a check interval and route notifications to email and SMS, alerting on sustained breaches rather than a single sample.

A tip worth knowing: if a caching layer sits in front of the endpoint, it can hand the monitor a stale copy instead of a fresh read. ostr.io supports a {{rand}} placeholder in the endpoint URL that generates a unique URI per request, defeating the cache so every check pulls live data — see the uncacheable path technique. With ostr.io Monitoring the whole setup is UI-driven: add the endpoint, let it parse the JSON or XML, choose the field and trigger, done.

Screenshot walkthrough

ostr.io custom data monitoring: first-level JSON/XML fields parsed into live charts with alert triggers.

The screen above shows custom data monitoring in action. Each first-level numeric field the parser found in your response becomes its own charted series, plotted over the selected time window, so a metric that's trending the wrong way is visible well before it becomes a page. Alongside each series sits its configured trigger — the threshold that, once crossed, sends the alert. What makes this powerful is that the values are yours: the chart isn't tracking generic CPU or latency, it's tracking whatever your application chose to expose, from concurrent sessions to a downstream dependency's health flag. And since ostr.io fetches the endpoint from outside your infrastructure, the reading reflects what an external client would actually receive across the full network and TLS path — a fresh, independent measurement rather than an internal number the server reports about itself.

Use cases

• Queue and backlog depth — Chart a worker queue's length and alert before it snowballs into dropped jobs.
• Application health flags — Expose a computed healthy figure or error count and catch problems that still return a 200.
• Data freshness — Surface a "seconds since last update" value and get told when a feed or cache goes stale.
• Business KPIs — Track live signups, orders, or active sessions from a lightweight JSON endpoint without a heavy analytics pipeline.
• Dependency status — Report a downstream service's reachability as a number and monitor it from outside, alongside your own server's SNMP sensors.