Availability Monitoring
Website availability monitoring answers the one question every other metric orbits: can people actually reach your site right now? Not "is the server powered on," not "is CPU healthy" — is the URL responding, quickly, with the right status code. This page is about that specific check. We'll cover what availability monitoring measures, the three signals it rolls together, how to set it up, and why running it from outside your own network is the part that makes it trustworthy when things go wrong.
What is Availability Monitoring
Availability monitoring is the continuous verification that a web endpoint responds successfully to requests. Strip it down and it's three readings taken together on every check: response time, HTTP status code, and uptime. Response time is how long the round trip took. The status code is what the server returned — a 200 means it served the request, a 5xx means it choked. Uptime is the share of checks that succeeded over a window. Watched together, these three describe whether a service is not just alive but usable.
This is the layer you reach for the instant a URL matters to anyone. A landing page, an API, a checkout endpoint, a login screen — if downtime costs you customers or trust, you monitor its availability. The distinction worth holding onto: internal server metrics can look perfectly healthy while the site is unreachable, because a broken proxy, an expired TLS certificate, or a DNS misconfiguration sits in front of the application. Availability monitoring tests the whole path a visitor travels, which is why it catches outages that a server-side dashboard cheerfully misses.
How it works
The mechanics are refreshingly plain. On a schedule you define, the monitor sends a request to your URL, times the exchange, and inspects the reply. It records the response time, reads the status code, and marks the check as a success or a failure. Over many checks those pass/fail results become an uptime percentage. When a check fails — or a run of them does — the system raises an alert. No agent, no code on your server; just a request and a verdict.
Here's how the three signals map to what they reveal:
| Signal | What it tells you | Common trigger |
|---|---|---|
| Response time | End-to-end latency of the request | Overloaded backend, slow query, network congestion |
| Uptime status code | Whether the server served the request correctly | 5xx crash, 403 auth break, unexpected redirect chain |
| Uptime percentage | Reliability across a time window | Flapping service, partial outage, SLA breach |
Response time monitoring is the early warning of the set. Latency usually creeps upward before an outright failure, so a rising response-time line often gives you minutes of lead time. The status code is the blunt verdict — served or not. And because these checks originate outside your infrastructure, they hold up under the exact conditions that matter most: when the server is too overwhelmed, or too crashed, to report on itself. That independence is the double durability principle applied to reachability.
One detail separates a useful monitor from a noisy one: how it treats a single failed check. Networks hiccup. A lone dropped request, a momentary DNS blip, a garbage-collection pause — none of these means your site is down, and a monitor that pages on every one of them trains you to ignore it. The fix is to require confirmation. Wait for a small run of consecutive failures before declaring an incident, and treat the recovery the same way, so a flapping service doesn't alternate between "down" and "up" alerts every minute. The result is a signal you actually trust, which is the whole point of measuring availability in the first place.
Setup
Getting website availability monitoring running is a short, ordered process:
- Choose a meaningful URL. Prefer an endpoint that exercises the real stack — a health route that touches the app and its database — over a static page a cache could serve while everything behind it burns.
- Set the healthy status code. Usually 200, but pick whatever your endpoint returns on success so a legitimate 204 or 301 isn't flagged as a failure.
- Define the response-time ceiling. Decide the latency past which you want to be told. Base it on the endpoint's normal behavior, not a guess.
- Pick a check frequency. Tighter intervals detect outages sooner; a minute or two suits most production endpoints.
- Tune the alert rule. Require a few consecutive failures before paging so a single dropped packet doesn't wake anyone. Route the alert to email and SMS.
In ostr.io Monitoring this collapses into a few clicks: open Monitoring, add an endpoint, select the server or URL, set the protocol to HTTP or HTTPS and choose a check frequency, then save. Response time, status code, and uptime are tracked automatically from that point — there's genuinely nothing to install, because the checks run on ostr.io's side, external to your network.
Screenshot walkthrough
The ostr.io availability monitoring dashboard: response-time graph, live status code, and uptime percentage on one screen.
The dashboard above is availability monitoring made visible. The response-time graph is the centerpiece — a line tracing latency across the selected window, where a slow upward drift is your first, quietest hint that something's straining. Next to it sits the current HTTP status code, the plain up-or-down verdict, and an uptime percentage summarizing reliability over the period. Reading them together is where the value lives: a latency spike that lands at the same moment the status flips to 5xx marks the start of an incident and roughly when it began. Because every point on that graph was measured from outside your network, it reflects what a real visitor experiences across the full DNS, TLS, and network path — not an internal self-report a struggling server might be unable to send at all.
Use cases
- Storefront and landing pages — Catch a dark homepage within a minute, before customers report it for you.
- API endpoints — Confirm a REST or JSON route keeps returning 200s and stays under its latency budget after every deploy.
- TLS and proxy failures — Detect expired certificates or misrouted reverse proxies that leave internal metrics looking green while visitors get errors.
- SLA evidence — Accumulate uptime percentage over weeks to prove — or contest — a service-level agreement with hard numbers.
- Multi-region reachability — Verify a site answers correctly from outside its own datacenter, not just from a machine sitting beside it.
