Back to the blog
BackendPublished 4 min read

How to Catch Website Errors Before Customers Complain

Most customers don't report a broken website; they simply leave. Simple monitoring lets you find out first and fix things faster.

A man using his phone at his desk late at night
Photo by Vitaly Gariev on Unsplash

Many business owners only find out their website has a problem when a customer complains in chat. And those are the patient customers. Most simply close the page and buy elsewhere. The good news is you don't need a big team to find out first. This article covers sensible layers of monitoring for a small business, and what we've already put in place at Numekara, the education business we run.

1. Log every server error

A 500 error means the server failed to handle a request because of a problem in the application, not a user mistake. Every such error should be recorded in full: when, on which page, and what the error message was. Without a record, developers can only guess.

At Numekara, every 500 error is saved straight to the database. Email addresses and database values are removed before saving, and records delete themselves after 30 days. The owner can search errors on an admin page and export the list to CSV.

2. Monitor availability from outside

Error logging doesn't help if the server goes down completely, because a dead server can't report anything. That's what availability (uptime) monitoring is for: an external service opens your website every few minutes from outside and sends an alert if there's no answer. Many such services have a free plan; check the limits and terms before you choose.

To be honest, Numekara's system page doesn't cover uptime monitoring yet. We have an uptime-check script, but we deliberately don't run it on GitHub Actions, because running it every 10 minutes would use more than the entire monthly free minutes. The lesson: availability checks are best run by an external monitoring service built for the job.

3. Send alerts where people actually look

An alert that lands in an inbox nobody opens might as well not exist. Send it to a channel your team reads every day, such as Telegram, with email as a backup. At Numekara, admins get a Telegram message and an email for new leads, payments, and problem reports. Each event goes to every active channel at once, so if one channel fails, the others still work. The business data is saved to the database first, and only then is the notification sent.

4. A problem report form with automatic context

A report like "the website is broken" is hard to act on. A good report form fills in the technical details itself, so the user only has to describe what happened. At Numekara, a report-a-problem button sits on every page, and the form:

  • Automatically includes the page, device, screen size, app version, and the last error code.
  • Accepts a screenshot that uploads straight to private storage.
  • Is protected by submission limits, a bot trap, and Cloudflare Turnstile.
  • Lands in an admin dashboard to be given a status and priority, and the reporter gets an email once it's resolved.

5. Correlation codes: the bridge between reports and logs

A correlation code is a unique number for one request to the server, much like a tracking number. At Numekara, the same code appears in the server's error record, in the error message the user sees, and in the problem report. So when a user sends a screenshot of an error message, the owner just pastes the code into the system page to see the matching error, without combing through thousands of log lines.

6. A system health page

A health page sums up the state of the system in one place. Numekara's system page shows recent errors, backup status, email usage, and database quota, so the owner can check without logging in to the server. When a new version is released, the server also goes through an automatic health check, and visitors are only routed to the new version once it passes.

Setting priorities

  1. Immediately: the website won't open, payments fail, or users can't log in.
  2. Today: an important feature is broken for some users, such as a form that won't send on one type of phone.
  3. Scheduled: messy layout, typos, or problems that have a workaround.

Also decide who is on duty to respond, and update customers who reported a problem even before the fix is done.

Start simple

For a static website with no login, an external uptime monitor and one clear contact channel are often enough. Error logging, correlation codes, and a full report form are worth it once your website has user accounts, payments, or data that keeps changing.

A customer who reports a problem is giving you a second chance. The ones who don't report usually don't come back.