Monitoring errors in production means tracking when your application fails for real users: how often it fails, where, and with enough detail to fix it. The aim is simple, to find errors before your customers do, instead of hearing about them in a support ticket. Here is what counts as an error, why they slip past you, what to measure, and how to catch them first.
What counts as an error in production
Not everything called an error is your problem, and not every problem looks like an error. It helps to be clear about the kinds you actually need to watch.
- Server errors (5xx). The HTTP spec defines the 5xx range as the server being aware it failed or cannot handle the request.1 These are almost always yours to fix, and they are the first thing to watch.
- Client errors (4xx) that are really your fault. The 4xx range means the request looked wrong.1 A lot of 4xx is genuinely the client, but a spike in 400s or 404s often means you shipped a bad link or broke an API contract.
- Unhandled exceptions. Code that threw and was not caught. These may or may not reach the user as a 500, but they are bugs either way.
- Failed background work. A queue job, cron, or webhook that failed quietly. No user saw a status code, but the work did not happen.
- Silent failures. The worst kind. The request returns 200, nothing throws, and the result is simply wrong: a charge that did not go through, an email that never sent. No error signal at all unless you check the outcome.
The first four show up if you are watching status codes and exceptions. The last one is why error monitoring alone is not enough, and why investigation matters: you often learn about silent failures from a symptom, not an error.
Why production errors slip past you
Most teams are not missing errors because they lack tools. They miss them for a handful of ordinary reasons.
- They are logged, but nobody reads logs. The error is sitting in a log file or a stream nobody opens until something is already on fire.
- They are caught and swallowed. A try/catch that logs and moves on means the code keeps running and the failure never surfaces.
- They hide inside the volume. A 0.5% error rate is invisible by eye and very real to the few hundred users hitting it.
- The alerts are noise, so the real one gets ignored. When everything pages, nobody looks. We wrote about this in alert fatigue.
What to actually measure
Errors are one of the four golden signals from Google's SRE practice, the small set of things worth watching above all else.2 For errors specifically, a few measures carry most of the weight.
| Measure | Why it matters |
|---|---|
| Error rate, per route | A failing /checkout matters far more than a failing /favicon. Aggregate rates hide this. |
| New vs known errors | A brand-new error after a deploy is the highest-signal event you have. |
| Affected users (blast radius) | Ten errors from one bot is noise; ten errors from ten paying customers is an incident. |
| Error budget burn | Against a reliability target, are you spending your allowed failures faster than planned? |
That last row is worth knowing about. Instead of chasing a perfect zero, the SRE approach sets an error budget: pick a target like 99.9% of requests succeeding, and treat the remaining 0.1% as failures you can afford.3 You act when you are burning the budget too fast, which keeps you from paging on every single error while still catching the ones that add up.
How to catch errors before customers do
- Capture errors at the source. Instrument with OpenTelemetry. It records failed requests and lets you set a span's status to error and attach the exception, so a failure carries its stack trace and context, not just a log line somewhere.4
- Track error rate on the routes that matter. Not every endpoint. The ones tied to money and trust: checkout, login, the API customers depend on.
- Alert on the two things that mean something. A spike in error rate, and any brand-new error type. Both usually trace back to a recent deploy, which makes them easy to act on.
- Make the path from alert to cause short. An alert that says "errors are up" without telling you why just starts a scramble. You want to go from the spike to the trace and the log line behind it in seconds, not by opening five tabs.
Catching and investigating errors with Fixter
The first three steps above are table stakes. The fourth, getting from an alert to the cause, is where small teams lose the most time, and it is what Fixter is built for. It instruments with OpenTelemetry, watches the error rate on the routes that matter, and surfaces new errors when they appear. When one fires, it does the first pass of the investigation for you: it pulls the relevant traces and logs, identifies the root cause, and maps the blast radius, who is affected, since when, and how badly. You ask in plain language from your editor and get the answer back:
The stance is investigation, not fixing: Fixter tells you what broke and who it hit, and you decide and guide the fix. If error tracking is most of what you need today, the Sentry alternatives guide covers the tools built for that, and error monitoring sits inside the wider picture in APM for small teams.
Key takeaways
- Watch 5xx, the 4xx spikes that are your fault, unhandled exceptions, failed jobs, and silent 200 failures
- Errors usually slip past because they are logged but unread, caught and swallowed, or hidden in the volume
- Measure error rate per route, new vs known errors, affected users, and error budget burn
- Capture errors with OpenTelemetry, alert on spikes and new error types, keep the path to root cause short
- The slow part is the investigation; Fixter does the first pass and hands you the cause and blast radius
Frequently asked questions
What does it mean to monitor errors in production?
Monitoring errors in production means tracking when your live application fails for real users: how often it fails, on which routes, and with enough detail to fix it. The point is to find errors yourself, from your own signals, before a customer hits one and opens a support ticket.
How do you detect errors in production?
Capture errors at the source by instrumenting your app, usually with OpenTelemetry, which records failed requests and unhandled exceptions automatically. Then track the error rate per important route, alert when it spikes or when a brand-new error appears, and keep a fast path from the alert to the trace and log line that explain it.
What is a good error rate?
There is no universal number; it depends on the route and what users expect. The practical approach from Google's SRE practice is an error budget: pick a reliability target, say 99.9% of requests succeed, and treat the remaining 0.1% as a budget you can spend. You react when you are burning it faster than planned, not to every single error.
Why do production errors go unnoticed?
Usually because they are logged but never read, caught and silently swallowed in code, or do not crash anything (a wrong result returned with a 200). Low-rate errors also hide inside high traffic, and when alerts are noisy the real ones get ignored. None of these show up unless you are watching error rate deliberately.
What is the difference between error monitoring and APM?
Error monitoring focuses on failures: what broke, how often, and for whom. APM (application performance monitoring) is broader, covering latency, traffic, and saturation alongside errors. Errors are one of the four golden signals APM watches, so error monitoring is a focused piece of APM, not a separate discipline.