Error monitoring is software that records every failure in a running app, with the code location, the user's steps, and the affected version, and alerts the team. Combined with uptime checks that test the site from outside, it means you learn about a problem from a notification within minutes instead of from a customer complaint days later.
Most bugs are never reported. A customer hits an error, tries once more, and leaves. If they are generous they send an email that says "the site is broken", with no detail about what they did or where.
CoverageCobra, our marketplace for court appearance coverage, runs error monitoring in production for that reason. Money moves through it and hearings depend on it. Waiting for a user to describe a failure is not an acceptable way to find one.
This post explains what error monitoring is, what it should and should not alert you about, and what a small app needs at minimum.
What is error monitoring?
Error monitoring is a service that catches errors in a live application, in the browser and on the server, and sends each one to a dashboard with the details needed to fix it. It groups repeats of the same error together, counts how many users were affected, and notifies the team according to rules you set.
It works through a small library added to the app. When code throws an error that nothing handles, the library records it and sends a report. The app carries on, or fails, as it would have anyway. The difference is that somebody now knows.
That is different from server logs. Logs are a stream of everything, which you search after you already suspect a problem. Error monitoring is a list of specific failures, sorted by how often they happen, that comes to you.
It is also different from testing. Tests catch the problems you thought of before release, which we cover in how software is tested before launch. Monitoring catches the ones you did not think of, on the devices and data you did not have.
What does error tracking capture?
Error tracking captures the error message, the exact file and line where it happened, the chain of function calls that led there, the browser and device, the page address, the version of the code that was running, and a trail of what the user did just before. Together those usually make a bug reproducible.
| What is captured | Why it helps |
|---|---|
| Error message and type | Says what went wrong |
| Stack trace | Shows the file, line, and calls that led to it |
| Release or version | Shows which deploy introduced it |
| Browser, device, operating system | Explains bugs that only happen on some devices |
| Page address and action | Shows where in the product it happened |
| Breadcrumbs | The clicks and requests just before the failure |
| Count and users affected | Tells you whether it is one person or everyone |
| First seen and last seen | Tells you whether it is new, old, or already gone |
Two setup details make the difference between useful and useless. First, upload source maps. Production JavaScript is compressed into something unreadable, and source maps let the tool show the original code. Second, tag every deploy with a release name, so a new error can be tied to the change that caused it.
There is a privacy side as well. Error reports can accidentally include what a user typed, a token in a web address, or personal details in a request. Configure the tool to scrub sensitive fields before anything is sent, and never include passwords, card data, or secret keys. Our rules for those are in environment variables and secrets.
Which alerts are worth waking up for?
The alerts worth waking up for are the ones where customers are being harmed right now and a person can do something about it: the site is down, payments are failing, sign-in is broken, or the error rate has jumped sharply after a deploy. Everything else can wait for working hours.
Alert fatigue is the real failure mode here. A team that receives two hundred notifications a day stops reading them, and the one that matters goes by with the rest. An alert that is always ignored is worse than no alert, because it creates the impression that someone is watching.
A workable split is three levels:
- Interrupt someone now. The site is unreachable, a payment or payout step is failing, sign-in is failing, or errors have spiked far above normal.
- Tell the team channel. A new kind of error appeared, an old fixed error came back, or a scheduled job did not run.
- Put it in a weekly review. Low-volume errors, warnings from old browsers, noise from browser extensions and bots.
The third level needs pruning. Much of what a browser reports is not your bug: extensions injecting broken scripts, crawlers poking at pages, a visitor's connection dropping. Filter those out, or the list becomes unreadable.
Whichever level an alert is in, it should name the problem and link straight to the detail. "Error rate high" at three in the morning is not much to go on.
What is the difference between uptime monitoring and error monitoring?
Uptime monitoring checks from the outside whether your site responds at all. Error monitoring reports from the inside what went wrong in code that ran. You need both, because each is blind to what the other sees: a site that is completely down sends no error reports.
An uptime check is simple. A service somewhere else requests a page every minute or so and alerts you if it fails or is slow. A few things make it more useful:
- Check a page that exercises the app, not only the homepage. A health address that touches the database tells you more than a static file.
- Check from more than one location, so one network's hiccup does not page you.
- Watch scheduled jobs. A job that fails to run throws no error. Have each job report in when it finishes, and alert when a report is missing. We explain scheduled jobs in what is a cron job.
- Watch the certificate and the domain. Both expire, and both take the whole site down when they do.
What does a small app need at minimum?
A small app needs four things at minimum: an error tracker on the front end and the back end, one uptime check on a page that uses the database, an alert that reaches a real person's phone, and a habit of looking at the error list after every deploy.
That is an afternoon of setup. Many monitoring services have a free or low-cost starting tier, so cost is rarely the obstacle. Check current plans yourself, since they change.
A static brochure site needs less. There is no application code to fail, so an uptime check and a test of the contact form cover most of the risk. A form that silently stops sending is the classic invisible failure, and we discuss it in SMS and email notifications in apps.
The habit matters more than the tool. On CoverageCobra nothing merges unless type checks, lint, tests, and the build pass. Monitoring is the other half of that gate: the checks run before the release, and the error list is what we read after it.
Frequently asked questions
Does error monitoring slow down a website?
A well-configured error tracker adds a small script and sends data only when something goes wrong, so the effect on speed is slight. Optional extras, such as recording every session, cost more. Turn on only what you will actually read.
Is error monitoring the same as analytics?
No. Analytics counts visits and behavior to answer business questions. Error monitoring records failures to answer engineering questions. They overlap a little on performance data, but neither replaces the other.
Who should receive the alerts?
Someone who can act on them. If a developer or agency maintains the app, urgent alerts should reach them directly. The business owner should still have access to the dashboard and know that monitoring exists.
Can monitoring be added to an existing app?
Yes. Adding an error tracker is usually a small library and a few lines of configuration, with no rewrite of the app. An uptime check needs no code change at all, only the address to watch.
If your app has no monitoring and you would like to know what it is doing, we can set that up. Contact us.