Green lights and angry customers
The uptime monitor has been green all month. Yet a customer emails to say the booking form showed an error, twice. Another says their order confirmation never arrived. Sales mention that a few enquiries from the website seem to have gone missing. When the developer tries it, everything works.
The site is up. Parts of it are failing for some people, some of the time, and nothing is recording it.
Why errors stay hidden
- Uptime checks only load a page; they do not submit forms, pay or log in.
- Errors in the browser (JavaScript failures, blocked scripts, old browsers) never reach the server logs.
- Server errors are logged to a file on the server that nobody reads.
- Background jobs, webhooks and scheduled tasks fail without any user-facing page to break.
- Errors are caught and swallowed in code, so the user sees a generic message and nothing is recorded.
The intermittent ones are the hardest. An error that affects one browser version, one payment method or one kind of customer record does not show up when a developer tests the happy path.
The cost of errors you never see
| Hidden error | Business effect |
|---|---|
| Checkout script fails on some phones | Lost sales with no trace in the reports |
| Form submission errors | Enquiries that never arrive |
| Payment webhook fails | Orders paid but not marked as paid |
| Email job stopped | Confirmations and invoices never sent |
| API errors for one integration | Partner data quietly out of date |
There is an internal cost too. When a customer does report a problem, the developer has nothing to go on: no stack trace, no browser details, no record of what the customer did. Hours go into trying to reproduce something that may depend on a phone model or an unusual order. Often the ticket is closed as could not reproduce, and the error carries on.
Customers who hit an error rarely report it. Most leave. The few who complain are a small visible share of a larger number who gave up quietly.
How we surface them
- Add application error tracking, using Sentry, New Relic, Datadog or similar, to the server side, so every unhandled exception is recorded with a stack trace, request details and the release it came from.
- Add browser error tracking to the front end, so JavaScript failures on real users' devices are captured with browser and page details.
- Stop swallowing errors. Where code catches failures, it records them before showing a friendly message.
- Monitor background work: heartbeat checks for scheduled jobs, alerts for queues that stop moving, and logging for failed webhooks.
- Group and route. Errors are grouped by cause, linked to the release that introduced them, and sent to a named person through Slack, Teams or email, with thresholds so a single odd error does not wake anyone.
- Add synthetic checks for the key journeys (submit an enquiry, complete a test checkout) on a schedule.
- Review regularly. A short, regular look at the top errors turns them into fixes rather than background noise.
On choosing tools: Sentry is strong for developer-focused error tracking, while New Relic and Datadog cover wider performance monitoring. Which suits you depends on your stack, team and budget, and we explain the trade-off rather than defaulting to one.
When errors are visible
When something fails for a customer, the right person sees it with enough detail to fix it, often before anyone complains. Errors are tied to the release that caused them, so bad releases are rolled back quickly. Background jobs that stop are noticed the same day. And the gap between what monitoring says and what customers experience closes.
Is this happening to you?
- Customers report errors that your team cannot reproduce.
- Your monitoring checks only that the site loads.
- Enquiries, orders or emails occasionally go missing.
- Nobody reads the server's error logs.
- You have no alerts for scheduled jobs or webhooks that stop.