Application Monitors

Alert on how your application is actually behaving — response time, error rate or throughput — measured from the traces it already sends, not from a probe.

How an application check works

An Application monitor doesn't send anything to your application. On every check it looks at the traces your application has sent to Zharp over a recent window — the last 5 minutes unless you change it — takes one measurement for a service, and compares it with your threshold. Because it measures real traffic, it sees what your users see.

Your application has to be sending traces first. If it isn't yet, start with Tracing Setup: add @zharp/apm to a JavaScript app, or point an existing OpenTelemetry setup at Zharp.

A value exactly on the threshold passes. A request is a span where the service received work: an incoming call (a SERVER span) or a message it consumed (a CONSUMER span). The database queries, outgoing calls and other work traced inside each request aren't counted as requests of their own, so they don't pull the response time down or multiply the throughput. A service that only reports other kinds of spans — a background worker with internal spans, say — is measured over all of them instead. A browser-only app is the same case: it sends only its outgoing fetch and XHR calls, so the monitor measures those — third-party calls included — and a failed call counts as an error. To judge one endpoint on its own, choose it under Operation.

The check reads traces Zharp already holds rather than reaching out from a location, so the form has no Regions section for this type. Check frequency decides how often it runs; the window decides how much traffic each check looks at.

Create an application monitor

1. 1
   Choose the type

   On the Monitors page, click New, open the type picker and choose Application monitor. It is listed under Application & APIs.

2. 2
   Pick the service

   Service lists every service that has sent traces in the last 24 hours, by the name it reports in its traces (its service.name). The first one is selected for you. If none has, the form shows Send traces to Zharp to start monitoring with a Read setup guide link, and the list reads No services reporting yet.

3. 3
   Narrow it to one operation, if you need to

   Operation is All operations unless you pick one — the list holds the operations the service reported in the last 24 hours, such as GET /checkout. Leave it on All operations unless one endpoint is what matters.

4. 4
   Set what to alert on

   Choose the measurement under Alert on and set Threshold. Changing Alert on resets the threshold to that measurement's default, so a latency in milliseconds is never left standing as an error-rate percentage. Then choose the window under Measure over.

5. 5
   Create it

   Pick who is alerted under How should we escalate incidents? and click Create monitor. If you leave the name empty, the monitor is named after the service, followed by the operation when you picked one (checkout-api · GET /checkout).

Settings

Check frequency, the confirmation and recovery periods and the other settings every monitor has are described in Monitor Types.

When there is no traffic

With no traces from the service in the window, there is nothing to measure a response time or an error rate on. The check records No traces from checkout-api in the last 5 minutes. and the monitor's status doesn't change: a new monitor stays pending, a monitor that was up stays up, and one that was down stays down, with its incident open, until traces arrive again and pass. A quiet night doesn't become an outage.

Throughput is the exception — no traffic is exactly what it watches for. Zero requests is below any threshold, so the check fails with checkout-api received no requests in the last 5 minutes. To be told when a service stops receiving traffic, or stops sending traces, add a second monitor on Throughput.

When it goes down

Each check records a sentence with the measurement, the window and, when it fails, the threshold it crossed. The service name comes first, followed by the operation when you picked one (checkout-api · GET /checkout).

Measurements are rounded to one decimal place. A failing check opens an incident like any other monitor, and the monitor comes back up — closing the incident — once a check passes again (after the recovery period, if you set one).

The monitor page

An application monitor's page shows the service as the traces describe it:

• The service and operation being watched, with HEALTHY, DEGRADED or NO TRAFFIC.
• Response time (p95) — a chart of the 95th percentile at each check, with the latest p50, p95 and p99.
• APDEX SCORE — a 0 to 1 score of how many requests were fast enough, rated HEALTHY, FAIR or POOR, with Error rate, Throughput per minute, p95 latency, the Apdex target and the number of Requests in the window. For a response-time monitor the target is your threshold, capped at 2,000 ms; for error rate and throughput it is 500 ms.
• Top endpoints — the service's five slowest operations by p95 over the last hour, with requests per minute and error rate. On a response-time monitor, endpoints over your threshold are highlighted.
• Recent checks — one row per check with the operation doing worst, p95, error rate and throughput. Expand a row for the measurement against the threshold (BREACHED or WITHIN), the window, p50/p95/p99 and Apdex, and a link to a trace from the worst operation — an erroring one first, else the slowest.
• The Service card with the settings in force and Open in APM, which takes you to the service's traces.

Troubleshooting

My service isn't in the list

Only services that sent traces in the last 24 hours are listed. Check that your application is sending them — see Tracing Setup — and that it sets the service name you expect. Two deployments reporting different names show up as two services.

The monitor stays pending

Read the latest check under Recent checks. No traces from … in the last 5 minutes. means nothing arrived in the window: the service had no traffic, or traces stopped reaching Zharp. A longer Measure over window helps for services with little traffic.

It alerts on a single slow request

In a quiet window, a handful of requests decide the percentile. Measure over a longer window, alert on Response time (average), or set a Confirmation period so the breach has to last before anyone is alerted.

The numbers differ from the APM pages

The monitor measures the requests the service handled over its own window, while the APM service list counts every span the service sent — including the database calls and other work traced inside each request. Compare over the same time range, and look at the request operations (such as GET /checkout) on the APM pages to compare like with like.