Website availability monitoring: setting up continuous Uptime Monitoring

Uptime monitoring: where a site loses availability

Site availability doesn't drop "in general" — it drops at specific points, and each class of failure manifests differently for the user.

When the application goes down, the visitor sees a 5xx error and leaves; when the database is unavailable, the page opens but data isn't served, and it looks like "the site works, but doesn't work." Uptime monitoring is needed precisely to distinguish these scenarios, rather than simply recording the fact that something is "down."

A separate category is failures at the periphery that aren't visible from inside the application. A load balancer can take a node out of rotation, and some requests will start going nowhere, even though the service itself is alive.

An expired certificate turns site availability into zero for all browsers at once, while the server responds normally.

5xx errors on one of the backends behind the load balancer produce intermittent failures: for some users everything opens, for others it doesn't, and without external checks such a failure can go unnoticed for hours.

The cost of web application downtime depends on how quickly it was detected.

If the point of failure is only visible through customer complaints, the time to response is measured in tens of minutes, and every minute means lost orders and traffic that search engines recalculate not in your favor.

Continuous uptime monitoring shrinks this window to minutes: checks run from external nodes, recording the response code, response time, and page content, not just the fact of a connection.

Next, we break down how this is addressed: which checks are set up for each point of failure, how thresholds and alerts are configured so that the on-call engineer receives a signal about a real failure rather than noise.

What continuous availability monitoring provides

Continuous uptime monitoring moves site availability from a "we find out from the client" mode into a managed process.

Checks run from several geographically distributed nodes at intervals of tens of seconds, so a failure is recorded at the moment it begins, rather than hours later when the first dissatisfied user reports it.

Failure detection time is reduced from hours to minutes — this is the main measurable effect of availability monitoring.

The key engineering challenge here is not the number of checks, but their quality. A single ping from one node produces a flood of false positives: a brief network spike, a scheduled service restart, or a certificate renewal all look like an outage.

That is why a check is confirmed from several independent points, and the trigger threshold is configured to distinguish a real failure from transient noise.

The share of false positives drops severalfold — the on-call engineer stops reacting to every fluctuation and deals with genuine incidents.

The second layer is what exactly is being checked. The HTTP response code alone carries little information: a page may return a successful status while showing an application error or an empty template.

That is why not only availability is monitored, but also response content, response time, and the availability of critical scenarios — authorization, checkout, search.

This eliminates an entire class of failures in which the site is formally "alive" but the business function does not work.

The third effect is predictability of response.

When a signal arrives automatically and contains context (which node, which code, how long), recovery begins immediately, rather than with the diagnosis of "what actually happened." The check history provides an objective picture: how long the site was unavailable over the month, which nodes degraded, whether failures coincide with releases.

This turns conversations about reliability into work with facts — and makes it possible to close root causes rather than symptoms.

Ways to check: from the outside, from the inside, synthetic

Checks fall into three classes, and each answers its own question. External probes answer "do users see the site": a request goes out from independent nodes in different regions, and the response code, time to first byte, and full page delivery are recorded.

Internal agents answer "what is happening inside": they capture CPU load, memory consumption, queue lengths, database response time — things that aren't visible from the outside until it's too late.

Synthetic scenarios answer "does the path work end to end": a robot goes through authorization, adds an item to the cart, places an order — and fails if any step breaks, even when the homepage loads.

In practice, the classes don't replace but complement each other.

An external probe catches an outage within a minute, but doesn't explain the cause; an internal agent shows that the database is responding slowly, but won't tell you that the user can no longer see it; synthetic checks find a break in the business chain that both previous checks will miss.

Different regions are needed separately: routing and caching at the edge produce a different picture for a client from another city, and "it opens fine for us" stops being an argument.

The choice isn't binary: a working setup is usually built on external probes as the foundation, internal agents for diagnostics, and one or two synthetic scenarios for the most expensive paths. Next, we'll look at how this comes together into a single picture and where notifications go.

How we build availability monitoring

Uptime monitoring is not about installing a single check service, but a sequence of decisions: what exactly we check, from where, with what thresholds, and who receives the signal.

Below is the order in which we carry out implementation so that by launch there are no "blind" services and no false alarms.

1. Inventory of services. We compile a complete list of everything that must respond: the website, API, admin panel, payment gateway, integrations with external systems. For each one we record the owner and criticality — the check frequency depends on it.
2. Choosing check points. We determine which regions and networks we check from: external locations provide an independent view, while an internal point catches local network issues. This way we separate a failure on the client's side from a failure on ours.
3. Setting thresholds. We define the polling interval, response timeout, and the number of retries before triggering. We select the threshold to match the real load profile so that planned spikes do not turn into nighttime alerts.
4. Routing notifications. We distribute signals across channels and on-call staff: critical — a call and chat, degradation — an email during working hours. Every notification has an owner, otherwise it gets lost.
5. Testing with a drill failure. We take down a test service and watch the entire signal path: whether the threshold triggered, whether the notification arrived, and in what time. This way we test not only the sensors but also the people.
6. Handing over the procedures. We provide documentation: what each alert means, how to act step by step, whom to escalate to. The client's team can run monitoring on its own.

After launch, we compare actual triggers with expected ones and adjust the thresholds — the first weeks give the most honest picture.

Artifacts: configurations, dashboards, regulations

After monitoring is launched, the customer is left not with "panel access" but with working documentation and files that the system lives by and is handed over with.

Everything is stored in your repository and infrastructure — without being tied to our accounts and without manual settings "in the interface that only one person knows about."

• Check configuration — declarative files: which addresses and ports are polled, intervals, timeouts, number of attempts before triggering, degradation thresholds. Changes go through review and are versioned like regular code.
• Service map — a list of all control points with owner, criticality, and dependencies: what monitors what, what counts as a failure, and what counts as scheduled maintenance.
• Availability dashboards — a summary for each service: response time, share of successful checks, failure history, and maintenance windows. Separate panels for management and for the on-call shift.
• Alerting policies — routing rules: who and where a signal goes to, what is considered critical, where the on-call engineer receives a notification at night, and what goes into the queue for the morning.
• On-call instructions — a step-by-step breakdown of typical failures: how to confirm the problem, whom to involve, how to start a rollback, and how to log the incident.
• Response regulations — criticality levels, response time for each, escalation procedure, and post-incident review rules.
• Acceptance report — which checks are enabled, how alerting was verified, and what remained outside the monitoring perimeter.

The package is self-sufficient: a new engineer sets up observation using these files without verbal explanations, and when changing contractors, nothing has to be restored from memory.

Case Study: Reducing E-commerce Downtime

Before: Failures Were Noticed Through Complaints

An online store at the peak of seasonal sales: peak load on order processing, dozens of requests per minute.

Failures came in waves — sometimes the payment gateway was unavailable, sometimes the cart returned errors for some requests, sometimes one of the servers behind the load balancer went down.

They learned about it from customer calls and emails: while a complaint reaches the on-call engineer, while they reproduce the problem — dozens of minutes passed, and some orders were lost irretrievably.

What Was Changed

Continuous uptime monitoring was set up: availability checks from several geographically distributed points, separate scenarios for key user paths — login, adding to cart, checkout, payment.

Threshold rules were divided by criticality: a full site outage wakes the on-call engineer immediately, degradation of an individual service goes into a queue with a softer priority.

Alerts arrive in the work chat and on the phone, indicating the specific node and error type — the on-call engineer immediately sees exactly what went down, without manual diagnostics.

In parallel, certificate, domain, and external dependency checks were set up — the payment gateway and the delivery service. A failure on the partner's side is now visible just as quickly as an internal outage.

After: Response Is Several Times Faster

The average time to detect a failure dropped from dozens of minutes to seconds — the system records a deviation before the first customer notices it.

The on-call engineer receives a signal with the exact address of the problem and begins recovery immediately, rather than after a series of clarifying questions.

The share of incidents detected automatically grew to the overwhelming majority — complaints are no longer the primary channel.

For the business, this is a direct reduction of losses: every hour of e-commerce downtime means failed orders and customers who went to competitors.

We built monitoring on the basis of Zabbix with integration into the team's messengers — the client got a transparent picture of availability and a clear protocol for responding to failures.

How does uptime monitoring differ from APM?

Uptime monitoring answers one question: does the service respond from the outside and return a correct response. Checks run from external points, on a schedule, most often via an HTTP request to key addresses — the homepage, catalog page, order form, API endpoint.

The response code, time to first byte, and availability from different regions are recorded. If no response arrives or it arrives with an error, an alert fires.

This is the view through the customer's eyes: the system may be perfectly healthy inside, but if the load balancer returns an error or a certificate has expired, for the site visitor it doesn't exist.

APM looks inside the application and answers a different question: why a request is processed slowly or fails.

Here you can see the depth of transactions — the path of a request through services, the time at each segment, the share of errors, bottlenecks in database queries, queues, memory consumption.

APM catches degradation before it becomes an outage: response time grew by 40% — you can see that the cause is in a specific query, not in the overall load.

The difference is fundamental: uptime monitoring measures availability, APM measures performance and causes.

The first will say "the site is down," the second — "the site is up, but checkout takes three times longer due to a database lock." Availability versus performance is not a competition between methods, but two different classes of tasks.

Both are needed when a service is critical for revenue. The scheme is simple: external checks provide a signal about the fact of a failure and serve as the source of truth for the status page, APM provides material for root-cause analysis.

Without external checks, you learn about an outage from customers; without APM, you know that "something is slow" but spend hours finding the culprit.

In practice, uptime checks are set up for 5-10 key scenarios, while APM is connected to the services whose latency directly affects conversion.

We set up both loops in a connected way: an alert from an external check opens an investigation, and application metrics show which segment of the transaction degraded. Describe your architecture — we'll come back with an estimate and a coverage plan.

Common technical concerns

Uptime monitoring doesn't break at the launch stage — it breaks at the trust stage: if the on-call engineer is used to ignoring alerts, the system is useless. That's why below are the four concerns that most often come up during sign-off, and how we address them engineering-wise.

How do you check pages behind authentication?

A public check of the homepage says nothing about the user account area or checkout. We set up scenarios with a test account: login, walking through the key steps, verifying the expected response content, not just the status code.

The credentials are stored in a secure vault and never end up in check logs. This way, the exact paths whose failure is visible to customers are the ones under observation.

Won't the checks put extra load on the server?

The frequency and depth of probes are tailored to the real traffic profile: lightweight requests to critical endpoints run frequently, heavy scenarios — less often.

We spread the vantage points across different networks so we can distinguish an application failure from problems with a specific route. The load from monitoring stays within limits that don't affect page delivery to users.

We already have monitoring deployed — what happens to it?

We don't break what exists: first we take stock of the current checks and alerting rules, find duplicates and dead alerts, then migrate or extend them. We preserve the response history so the graphs don't have gaps. If some tools already cover the task — we keep them and build out the missing scenarios.

Let's discuss your monitoring task

So that setting up monitoring doesn't turn into a set of disconnected checks, we start by analyzing your infrastructure: which services are critical for the business, where the line runs between "the site opens" and "the order is placed," what failures have already happened and how you found out about them.

This determines what exactly we check — page availability, form response, payment processing, or the API chain between services.

Next, we gather the inputs without which the assessment would be approximate:

• a list of domains, subdomains, and external services that need watching;
• which user scenarios are considered critical and should be checked end-to-end rather than piece by piece;
• current notification channels and who is the first to take an incident into work;
• how access to the infrastructure is arranged and whether there are restrictions on external checks;
• expected response time: what makes a failure serious and what can be postponed;
• whether there are already monitoring systems and logs that you don't want to lose.

Based on this data, we prepare an assessment and a plan: which checks we set up, at what frequency, where we send notifications, and how we configure thresholds so as not to wake the on-call engineer for every fluctuation.

Separately, we discuss availability support after launch — who watches the monitoring itself so that it doesn't "go blind" at the right moment.

Describe the task in free form — which services, which failures are concerning, what you've already tried. We'll come back with an assessment and a monitoring setup plan for your environment.