Why Client-Side Errors Are Invisible
Why this matters: the previous chapter built a monitoring system that watches everything you own. This chapter is about the failures that happen outside it — and they are the ones that leave your dashboards green while users cannot reach you at all.
Key takeaway
Server-side failures are visible: monitor web and application server logs for elevated rates of HTTP 500 errors. Client-side errors are difficult to detect because the service lacks insight into the client's environment — and a request that never arrives leaves no log line.
The asymmetry
A server error produces a record. A failure to reach the server produces nothing — from your side, that user simply did not show up today.
The three failure classes
Several factors can prevent clients from reaching the server:
| Failure | What happens | What you see |
|---|---|---|
| DNS resolution failures | The client cannot turn your name into an address | Nothing — no connection is ever attempted |
| Routing failures | Traffic between the client and the service provider never arrives | Nothing — packets die in transit |
| Third-party infrastructure failures | A middlebox or CDN in the path fails | Nothing, or partial traffic from unaffected regions |
Why "watch for a traffic dip" fails
The instinctive workaround is to alert when traffic drops. This metric is unreliable. It produces false positives or negatives for two reasons:
| Problem | Detail |
|---|---|
| Natural load variability | Traffic falls at night, on weekends, after a marketing campaign ends. A dip is normal, so a dip-based alert either fires constantly or is tuned so loose it catches nothing |
| Partial impact | When issues affect only a small segment of users, the aggregate barely moves. A whole country losing access might be 2% of traffic — indistinguishable from noise |
This is gray failure, from outside
The Foundations module defined gray failure as the system's view of its own health disagreeing with its users' view. The monitoring chapter showed one version: a server passing health checks while dropping requests.
This is the extreme case. Every server is genuinely healthy, every metric is genuinely green, and the users cannot reach the building. There is no internal signal to find, because nothing internal is wrong.
Key takeaway
Server monitoring answers "is my infrastructure working?" Client-side monitoring answers "can users actually reach it?" Those are different questions, and the second one cannot be answered from inside.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "We'd monitor error rates in the server logs." |
| L5 | Sees the gap: "500s show server problems, but if DNS or routing fails the request never arrives and there's nothing to log." |
| Staff+ | Kills the obvious workaround: "you can't detect it from a traffic dip either — a whole country losing access might be 2% of volume, which is inside normal variance. The signal is a small population vanishing from a large one, so you have to hear from those users specifically." |
Next: a real outage nobody noticed.