# Why Monitor HTTP Client Errors

DevFeed: [Why Monitor HTTP Client Errors](<https://devfeed.tech/articles/ignore-http-client-errors-at-your-peril-19062.md>)

Original publisher: [Read original article](<https://httptoolkit.com/blog/how-and-why-to-monitor-http-client-errors/>)

Author: HTTP Toolkit; Tim Perry

Published: 2020-04-16T17:45:00Z

Content type: tutorial

Language: en

Sources: [HTTP Toolkit](<https://devfeed.tech/sources/http-toolkit.md>)

Topics: [HTTP](<https://devfeed.tech/topics/http.md>), [Monitoring](<https://devfeed.tech/topics/monitoring.md>), [Logging](<https://devfeed.tech/topics/logging.md>)

Tags: [backend](<https://devfeed.tech/tags/backend.md>), [debugging](<https://devfeed.tech/tags/debugging.md>), [errors](<https://devfeed.tech/tags/errors.md>), [http](<https://devfeed.tech/tags/http.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [monitoring](<https://devfeed.tech/tags/monitoring.md>)

## AI overview

The article explains why backend monitoring should include HTTP client-side failures that may not appear in standard server-error metrics or logs.

## Source excerpt

There's a lot that can go wrong when talking to servers on the web. When you're building and running a web service, keeping an eye on errors is essential to finding bugs, and understanding the experience of your end users (and hopefully even improving it). With so many possible forms of failure though, there's some critical cases that can fall through the cracks. Most backend monitoring and logging will detect and report on explicit server failures, from tracking the number of 5xx HTTP error responses that you send to reporting thrown exceptions to services like Sentry. For this post, I want to go beyond these surface checks, but that's not to say they're unimportant: before you do anything else here, I'd strongly recommend having that fundamental monitoring in place. In many cases though, those checks alone can offer a false confidence to teams, who assume that no explicit server errors means that everything is working fine. That's frequently not true. These don't tell the whole story, as there's a whole world of errors that matter to the backend, and whose root cause lies in the server itself, but which surface as client errors, and never get reported. The Client is Always Right When we talk about 'client' errors, I'm talking about errors that are typically blamed on bad client behavior. Think unexpected connection resets, semantically invalid HTTP requests, syntactically invalid HTTP requests, and the like. These are issues caused by how the client communicates with the server, rather than by the server's core application logic. They're often handled at a lower level of your HTTP stack, and logged and handled separately. 4xx errors often aren't included in default metrics, invalid or disconnected HTTP requests often don't get a response at all, and many of the raw errors these trigger will be handled and swallowed by your HTTP server or framework. These are near-invisible failures. They're ignored usually simply to manage the noise. There really are bad clients o