"Is the application healthy?" is a simple question that most dashboards cannot answer honestly. This guide covers every layer of the answer — and how to roll them into one number that means something.
Application health monitoring is the ongoing measurement of every layer a user depends on — availability, response times, error rates, frontend behaviour, APIs and third-party dependencies — combined into an honest, explainable picture of whether the application is working. The key word is explainable: a health score is only useful if you can say why it is 73 and not 95, and what would move it. This guide walks through each layer, how to measure it, and how mature teams roll the layers up using error budgets rather than arbitrary weightings.
"The app is up" collapses six distinct questions into one. A complete health picture keeps them separate, because they fail separately:
Most monitoring setups cover layer 1 and stop. Most incidents live in layers 2–6: the site is up and slow, up and erroring, up and broken in the browser, or up and failing because a payment provider is down. That mismatch — monitoring layer 1 while failing in layers 2–6 — is why teams with green dashboards still get complaint emails.
Availability sounds binary and is not. The honest measurement has three properties:
Availability should also be recorded, not just alerted on — the percentage over a month is the number an SLA conversation runs on, and it cannot be reconstructed after the fact if the checks were not stored.
Averages are where performance problems hide. If 95 requests take 200ms and 5 take 4 seconds, the average is a comfortable 390ms while one user in twenty is having a miserable time. Percentiles keep the miserable users visible:
The other half of performance health is trend. A p95 of 600ms is a fact; a p95 that has gone 200 → 250 → 310 → 440 → 650ms over five hours is a story — the shape a memory leak, a filling connection pool or an unindexed query growing with data makes. Health monitoring that only looks at the current value misses the story. Baseline comparison is what turns the story into a warning.
Error rate — failed requests over total — is the most direct health signal, with two subtleties. First, the baseline matters: 2% errors is catastrophic for a checkout API and normal for an endpoint probed by scrapers. Second, the mix matters: a shift from occasional 404s to any 5xx at all is a state change even if the total rate barely moves. Watch the rate against its own history, and watch 5xx separately from everything else — server-side failures are their own category.
Frontend health is the layer server-side monitoring cannot see at all. The server can deliver a perfect 200 whose JavaScript then throws on load, leaving a page that renders but does not work. The measurement is client-side: a lightweight script in the page reporting uncaught exceptions, unhandled promise rejections, and failed network calls back to your monitoring. The unit that matters is not the raw error count — busy sites always have some — but the count relative to that site's usual hour. Forty errors an hour every hour is a known bug; forty against a usual two is a deploy gone wrong.
Your own APIs deserve per-endpoint health, not one aggregate. "The API is 99.5% available" can hide a checkout endpoint at 94% behind a healthy search endpoint at 99.9%. Check the endpoints that map to money and user journeys individually, with expected-status and expected-content assertions, so a 200 returning an error page is caught for what it is. API failure detection covers this layer in depth.
Dependencies — payment providers, email services, hosting, CDN — are health you inherit but cannot fix. Monitoring them does two jobs. First, explanation: when your checkout fails because the payment provider is down, the incident should say so instead of sending your team hunting through their own code. Second, noise control: forty client sites failing because one CDN is down should be one story, not forty pages. Most major providers publish machine-readable status feeds; a health system should be consuming them.
Leadership wants one number. The temptation is to invent a weighting — availability 40%, performance 30%, errors 30% — and the problem is that the weights are arbitrary, so the number is unexplainable, so it gets ignored.
The method that survives scrutiny is the error budget, from the SRE tradition. It works like this:
The same construction gives you burn rate — how fast budget is being consumed right now versus the rate that would exactly exhaust it at month-end. Burn rate is the best severity signal available: 14× burn sustained for an hour is an emergency regardless of what the current health number says, because it tells you where the number is going. The complete reliability picture — budgets, burn, warnings and incident flow — is covered in the proactive reliability guide.
For a team starting from nothing:
The most honest single number for health is budget remaining against a declared target — see error budgets and SLOs for small teams.
| The six layers | Availability, performance, error health, frontend health, API health, dependency health |
|---|---|
| Availability rule | Outside-in checks, 1–5 minute interval, confirmed by consecutive failures before alerting |
| Performance rule | Track p50/p95/p99 percentiles and their trend — never the average alone |
| Frontend rule | Client-side error reporting judged against that site's own usual rate |
| Honest score | Error budget remaining: health = unspent fraction of the failure your SLA target allows |
| Severity signal | Burn rate — how fast the budget is being consumed vs the break-even rate |
| Time to first value | Checks and SSL monitoring same-day; baseline-driven warnings after ~2 weeks of history |
Application health monitoring is the continuous measurement of every layer an application's users depend on — availability, response times, error rates, frontend behaviour, APIs and third-party dependencies — combined into an explainable picture of whether the application is working and which layer is degrading when it is not.
A health score is only meaningful if it is derived from something verifiable. The most defensible construction is error-budget remaining: with a 99.9% monthly availability target, a score of 90 means only 10% of the month's allowed failure has been consumed. On that scale, anything above ~85 is comfortable, 50–85 deserves investigation, and below 50 means the month's target is in genuine danger.
An error budget is the amount of failure an availability target permits. A 99.9% monthly target allows 0.1% of requests or checks to fail — about 43 minutes of downtime. Teams spend the budget on incidents and (deliberately) on risky changes; when it is exhausted, the month's target is missed. Health expressed as budget remaining is explainable in one sentence, which arbitrary weighted scores are not.
Burn rate is the speed at which an error budget is being consumed, expressed as a multiple of the rate that would exactly exhaust the budget at period end. A burn rate of 1 means on-track to just miss the target; 14× sustained for an hour means roughly 2% of a monthly budget gone in that hour — an emergency signal even before users notice.
Outside. A check running inside your network shares your network's fate: it can report healthy while DNS, TLS or the load balancer is failing for everyone else. Outside-in checks traverse the same path as users and catch the failures internal checks are structurally blind to. Internal checks are a useful supplement, not a substitute.
Uptime asks whether the server answered; frontend health asks whether the delivered page actually worked in the browser. A deploy can ship JavaScript that throws on load — every uptime check passes, and every user meets a broken page. Measuring frontend health requires collecting errors from real browsers, not probing the server harder.
Automated evaluation should be continuous, with warnings surfacing in real time. Human review works best monthly: uptime against target per asset, the incident list with causes, and which early warnings did or did not come true. The monthly review is also what an SLA report to a client is built from.
Merik computes health exactly the way this guide describes, because the guide describes what we built. Every registered asset gets outside-in checks with confirmation, daily SSL expiry checks, and latency percentile baselines measured over 14 days. Its health score is error budget remaining against the SLA tier you declared — a 61 means 39% of the month's allowed failure is spent, and the number is traceable to individual checks. Burn rate over one hour, six hours and three days sets incident severity, so a Sev1 means the budget is actually haemorrhaging, not that someone guessed "critical" at registration time.
Frontend health comes from the merik.js snippet — browser errors, grouped and counted against that site's own usual hour. Dependency health comes from live vendor status feeds, so a Stripe outage explains your checkout incident instead of hiding behind it. And every layer rolls up into early warnings when it drifts, an auto-assigned incident when it breaks, and a printable monthly SLA report when a client asks how the month went.
Detecting problems before users report them — baselines, anomalies and early warnings, explained.
The complete checklist — uptime, APIs, frontend errors, certificates, dependencies, deploys.
SLO vs SLA, the minutes arithmetic, a health score as budget remaining, ship or stabilise.