Your Online Store is Probably Throwing Errors Right Now. You Just Don’t Know it Yet.

Not the kind that take the site down. The kind that affect a specific page, for a specific type of visitor, under specific conditions, and then disappear without a trace. The customer who hit it doesn’t report it. They just leave.

This happens on almost every ecommerce site in production. The question isn’t whether it’s happening on yours. It’s whether anyone is looking.

Before you can answer that, you need to know what you’re looking at. Your application logs and monitoring tools report errors as numbered codes. Here’s what each one actually means, and whether it’s worth your attention.

What the numbers mean

Every time a browser requests a page, your server sends back a numbered response code. These aren’t all errors. They’re responses, and most of them are good news. The codes run from 100 to 500. The 100s are informational, happening under the hood during connection handshakes. You’ll never see them in a report. The 200s mean everything worked. The 300s are redirects, mostly fine, though too many chained together can slow your site down.

The 400s and 500s are where problems live, though even then the distinction matters. 400-level responses mean something was wrong with the request: the wrong URL, missing permissions, bad input. The server understood what was being asked and said no. 500-level responses mean something went wrong on the server’s side. Your application tried to do something and failed. As a rule, 400s are often benign. 500s always need a look.

401 Unauthorised: the request requires a login. Bots probe admin URLs constantly and rack up 401s. Ignore unless you’re seeing them on pages that should be public.

403 Forbidden: logged in, but not allowed. Similar to 401 but the server knows who you are and still said no.

404 Not Found: the page doesn’t exist. Most common response on any site. Mostly benign (old links, bot probing, mistyped URLs) but worth a periodic audit. Old product pages still in Google’s index should be redirected, not left as 404s.

422 Unprocessable Entity: the request was understood but failed validation. Common on form submissions. Usually fine unless it’s appearing somewhere it shouldn’t be.

429 Too Many Requests: a rate limit was hit. Either your app is throttling someone, or an external API is throttling you. The second one causes real problems if not handled properly.

500 Internal Server Error: the server hit something it couldn’t recover from. Always investigate, then determine whether it’s real traffic or bots.

502 Bad Gateway: something between the user and your app couldn’t reach it. Usually a crash or a bad deployment. Check your process logs.

503 Service Unavailable: the app is running but can’t handle requests. Typically overload or a seized background process. Common during traffic spikes.

504 Gateway Timeout: the app didn’t respond in time. Usually a slow database query, or a payment gateway taking too long to respond. Find the bottleneck.

Not every error is worth fixing

Once you can see your errors, the next skill is knowing which ones matter. A meaningful portion of the errors on any ecommerce site aren’t coming from real customers. They’re generated by bots. Automated crawlers routinely probe websites by requesting pages that don’t exist, trying URL patterns beyond what your site supports, or pushing pagination further than your interface allows. Your site doesn’t know it’s a bot, so it throws an error, logs it, and moves on. These aren’t bugs. They’re your site correctly refusing to do something it was never designed to do.

The errors worth investigating are the ones occurring on legitimate pages, during normal user journeys, at a rate that suggests real people are hitting them. An error on /products?page=9847 from an IP in a data centre is not the same problem as an error on your checkout confirmation page from a customer in Melbourne on a Friday afternoon.

Errors versus error rate. Seeing fifty 404s in a month sounds alarming until you know your site had two hundred thousand visits. Seeing ten 500s in an hour on your checkout page is a crisis even though it’s a smaller number. Raw error counts tell you almost nothing on their own. Error rate, meaning errors as a proportion of total requests or errors per unit of time on a specific page, is what tells you whether you have a problem. Any monitoring worth using will show you rate, not just volume. If yours only shows totals, that’s the first thing to fix.

Help your users recover

An error page is still a page. Most sites waste it.

A 404 page that just says “Page not found” hands a frustrated customer a dead end. A useful 404 page includes a search bar, links to top categories, and a way to contact support. The goal is to keep the customer in the funnel rather than give them a reason to close the tab.

The same principle applies to 500 pages. “Something went wrong, we’re looking into it” with a link back to the homepage is significantly better than a blank screen or a technical error message. Some sites surface their support chat on error pages specifically because a customer who has just hit a problem is already frustrated and already thinking about leaving. Meeting them there with a human option can recover a sale that would otherwise be lost.

When is investing in error logging worth it?

When you’re doing enough transaction volume that invisible errors have a material cost. A site doing a handful of orders a week can probably manage with reactive monitoring and will hear about problems eventually. A site doing meaningful daily revenue cannot afford to find out about a broken checkout from a customer complaint two weeks after the fact.

The other trigger is any time you’ve made a significant code change or platform upgrade. Errors tend to spike after deployments, and you want to know about them within minutes, not at the next monthly report.

If you’re at either of those points and you don’t have error monitoring in place, the cost of setting it up is almost certainly less than one day of undetected checkout failures. And when you do spot one, writing a bug report your developer can act on immediately gets it fixed faster than a vague description ever will.

When does it make sense to fix bot-induced errors?

Almost never, with two exceptions.

The first is performance. If bot traffic is large enough to affect your server’s response times, real customers feel it. Thousands of requests hitting unhandled routes can slow down the pages that matter. At that point it’s worth implementing rate limiting or blocking the offending traffic at the network level.

The second is security. If a bot discovers that a sensitive file or configuration endpoint is returning a response it shouldn’t, that’s a fix-immediately situation regardless of the source. The origin of the request doesn’t change the exposure.

In every other case, the right response to bot noise is filtering it out of your monitoring so it doesn’t obscure the real signal. Not fixing the underlying “error,” because there’s nothing to fix.

One thing worth knowing before you look at a dashboard full of errors for the first time: the number will probably be higher than you expect. Don’t panic.

A significant portion of what you’ll see is bots. Automated crawlers probing your site for URLs that don’t exist, requesting page numbers beyond what your interface supports, or looking for admin panels they’ll never find. Your site is correctly refusing all of it. That’s not a bug count. That’s your site doing its job.

The errors that matter are the ones happening on real pages, during normal customer journeys, at a frequency that suggests actual people are hitting them. Finding those in the noise is the work. And it’s work that only gets done if someone is regularly looking.

If nobody on your team owns that, it’s worth asking who should.