Why Online and Offline Are Not Enough
A classic availability check asks a single question: does a response come back? The HTTP protocol, however, distinguishes five classes of status codes, from 1xx to 5xx, and only the 2xx class stands for genuine success (RFC 9110). A server answering with 503 Service Unavailable is reachable in the network sense - it does send a valid HTTP response - but delivers no usable content. Many simple monitors treat any HTTP response as up and therefore miss exactly the cases where the application is effectively broken. The 5xx class is the most critical of them, because it signals a fault on the server side that the visitor cannot fix and cannot resolve by clicking again.
Partial outages are particularly tricky. The health check on the home page dutifully returns a 200, while checkout, search or a single API endpoint is already stuck on a 500. Whoever checks only the home page sees a green light although the revenue-relevant part of the site is down. That is why 5xx monitoring belongs together with alerting that does not wait for total unreachability, but fires as soon as a growing share of requests is answered with server errors.
The business damage arises not at the server but at the visitor. The average shopping-cart abandonment rate in e-commerce is around 70 percent (Baymard) - a 500 during payment drives it up further, because the customer is rejected at the worst possible moment. And a 504 timeout, where the page seems to load forever, feels to users like a hanging application: around 53 percent of mobile visits are abandoned when loading takes longer than three seconds (Google/web.dev). Whether the cause is a slow database or a server error makes no difference to the abandonment - the result is lost revenue.
The 5xx Status Codes and What They Reveal
Not every server error has the same cause. The individual 5xx codes are a diagnostic signal that points the direction of the investigation (MDN). A 500 indicates a fault in the application itself, a 502 and 504 a problem between an upstream proxy and the backend, a 503 an overloaded instance or one under maintenance. Watching the distribution of these codes over time often lets you classify an incident before you even look at the logs.
| Status code | Typical cause | What monitoring infers |
|---|---|---|
| 500 Internal Server Error | Application or database fault, unhandled exception in the code | Regression after a deploy or a fault on a specific path |
| 502 Bad Gateway | Backend answers the proxy incorrectly, often after a failed deploy | Hung restart, crashed process or a misconfigured upstream |
| 503 Service Unavailable | Overload, DDoS or planned maintenance; capacity exhausted | Load spike, attack or a maintenance window that runs too long |
| 504 Gateway Timeout | Backend does not answer the proxy in time | Slow query, blocked process or a hanging third-party service |
This mapping matches what operators observe in practice: 502 and 504 typically appear right after faulty deploys, 503 during overload, DDoS attacks or maintenance, and 500 on application or database faults (StatusCake/Similarweb 2025). The standard also specifies that for a 503 the server SHOULD indicate via a Retry-After header when a retry makes sense (RFC 9110) - a signal that monitoring can read along and use to assess the duration. For forms in particular, capturing 5xx is valuable, because a 502 on submit loses a request silently; how to safeguard that is covered in the article on contact-form delivery.
How a 5xx Error Turns into an Outage
A single server error is rarely the end state - it is the start of a chain. The tricky thing about 5xx errors is that they cluster once a cause takes hold: a faulty deploy topples not one request but every request to the affected process, and a load spike escalates because rejected clients retry. The following four patterns are behind most server-error waves.
A new release fails to start cleanly, an environment variable is missing or a process binds the wrong port. The proxy gets no valid answer from the backend and returns 502 or 504 - often to the second from the deploy moment.
A campaign, a viral peak or automated attack traffic pushes load past capacity. The server throttles or capitulates and answers with 503, while legitimate visitors are rejected along with the rest.
An exhausted connection pool, a deadlock or an unhandled exception in the code produces 500s - often only on a specific path, so the home page looks healthy and the fault stays hidden for a long time.
An embedded third-party service or a slow query does not answer in time. The upstream proxy aborts and reports 504 - the application itself is healthy but hangs on someone else's delay.
The economic dimension of such outages is real. Around 81 percent of German companies were recently targeted by data theft, espionage or sabotage, with annual total damage estimated at about 267 billion euros (Bitkom 2024) - overload from attacks is among the triggers of 503 waves. At the same time, nearly half of internet traffic, precisely 49.6 percent, is now automated (Imperva 2024), which pushes server capacity to its limit unnoticed. Denial-of-service has for years ranked among the most common incident patterns according to the Verizon DBIR (Verizon DBIR 2024). A deploy, in turn, is the classic trigger of a 500 wave, which is why 5xx monitoring pairs well with checking deploy-induced regressions - such as an accidental noindex after a deploy. And when runaway page sizes put servers under load, a look at page weight and resource bloat helps.
A single 5xx response is an early warning signal, not an end state. Whoever watches the share of server errors sees the incident coming while only a small part of requests is affected. Whoever waits for the full outage only reacts once complaints are already arriving.
The Cloudflare Outage of 18 November 2025
How quickly a server error can be carried in from outside was shown by the incident on 18 November 2025: a disruption at Cloudflare triggered HTTP 500 waves across thousands of websites at once (Gremlin 2025). For the affected operators it was instructive, because their own servers were perfectly healthy - the error arose in an upstream layer to which they had no direct access. This is precisely where measuring from the outside proves its worth: monitoring that fetches the page the way a real visitor does sees the 500 regardless of whether the cause sits in your own data centre or at a provider.
Even if your server runs flawlessly, a CDN, a reverse proxy or an embedded third-party service can deliver 5xx responses to your visitors. An internal health check that only tests your own process will not notice this. Only fetching across the entire delivery path - the way the user experiences it - makes such externally caused errors visible.
Such dependencies grow the more an application is composed of embedded services. If an API your site pulls content from fails, that often surfaces to visitors as a 502 or 504. It is therefore worth checking critical interfaces separately - the article on API monitoring explains how individual endpoints, including status code and response time, can be watched.
Error-Rate Thresholds Instead of a Binary State
The decisive step away from a simple online or offline is the error rate. Instead of judging every single response as a binary success or failure, error-rate monitoring measures the share of 5xx responses over a time window - say the last five or fifteen minutes - and compares it to a threshold. If the 5xx share stays permanently below a fraction of a percent, that is healthy background noise. If it rises above a defined limit, for example 1 percent, it raises an alert long before the site is fully down.
The advantage of this view lies in its gradation. A single 5xx response during a brief load peak is often uncritical and would, under an all-or-nothing logic, either trigger a false alarm or vanish entirely. A threshold on the rate, by contrast, separates normal noise from an escalating problem: only when a meaningful and sustained share of requests is affected does it report. This keeps the notification meaningful, and the team does not get used to alerts it dismisses anyway. This continuous target-versus-actual check is the core of resilient uptime monitoring that goes beyond mere reachability.
A sensible error-rate threshold follows the normal background noise of the site. Do not set it on the first 5xx response, but on a share or a sustained cluster - that way monitoring reliably distinguishes a harmless outlier from a genuine, escalating server-error wave.
How XICTRAQ Monitors the 5xx Error Rate
The uptime and status-code monitoring by XICTRAQ checks your pages and endpoints at fixed intervals and turns the raw response data into understandable signals. The checks run from several locations, so a regional network fault is not mistaken for a genuine server error.
Every response is classified by its code. 5xx errors are counted separately and kept apart from 4xx responses, which indicate a problem on the request side.
The share of 5xx responses is computed over a time window. If it crosses your threshold, it raises an alert - not only at total unreachability.
Checks run from distributed regions. This lets a real server error be distinguished from a local network glitch and an outage be confirmed reliably.
Rising latency is captured as an early indicator and is often visible before the first 504 timeout occurs - a lead time that buys reaction time.
The status-code distribution is documented over time and can be shared as a status page - transparent towards customers and colleagues.
Every detected server-error wave is reported via email, Slack, Discord or Telegram - with context on the affected page and the status code.
When monitoring detects a server-error wave - a 5xx spike above the threshold or a sustained elevated error share - it triggers a notification via the channel you chose. The same data feeds the status page and reporting, so you can document the course of an incident afterwards. And because the notification runs through the same alerting as every other check, server errors land where your team is already looking.
5xx Monitoring as Part of the Availability Strategy
Monitoring the 5xx error rate does not stand alone - it is one building block of a resilient availability strategy. Alongside confidentiality and integrity, availability is one of the three classic protection goals of information security, which Germany's BSI also lists as a distinct goal in its IT-Grundschutz (BSI). A server can be reachable and still answer with faults; it can hold a valid certificate and still deliver 500s. Only the interplay of several checks yields a complete picture of the actual state from the user's perspective.
This is especially relevant for teams that deploy frequently, because every change can introduce a new source of faults. Server errors not seldom originate in front-end code or outdated dependencies - how to spot such risks early is shown in the article on vulnerable JavaScript libraries. The practical value of 5xx monitoring lies in the time factor: without monitoring, a server-error wave is typically noticed only when a user reports a broken feature - with continuous monitoring, the same incident becomes visible within minutes, often before a meaningful number of requests is affected.
Finally, a signal measured from the outside creates a shared factual basis. Development, operations and the business unit each see only a slice; the documented 5xx share gives all of them the same reliable foundation. Whoever keeps the history can also demonstrate to a provider when and how often its infrastructure delivered errors to their own visitors. Which scope of checks makes sense for this depends on your site - an overview of the included checks can be found in the pricing overview.
This article draws on data and standards from: MDN Web Docs (definitions of HTTP status codes 500, 502, 503, 504), RFC 9110 (HTTP semantics, the 5xx server-error class and the Retry-After header), StatusCake/Similarweb 2025 (typical causes of 500, 502, 503 and 504), Gremlin 2025 (Cloudflare outage on 18 November 2025 with HTTP 500 waves across thousands of websites), Bitkom 2024 (share of affected companies and total damage from attacks), Imperva 2024 (share of automated internet traffic), Verizon DBIR 2024 (denial-of-service as a common incident pattern), Baymard Institute (average shopping-cart abandonment rate), Google/web.dev (bounce rate for long load times) and the BSI IT-Grundschutz (availability as a protection goal). Figures classified as secondary are marked as such.