Monitoring and error tracking: how we know before users complain
What is watched on a live application, how errors reach a person with context, and why users should rarely be the ones reporting problems.
The short answer
A live application is watched in four ways: availability, whether it responds; errors, what the code is raising and for whom; performance, how long screens and requests take; and business signals, whether orders, sign-ups, submissions and payments are behaving normally. Error tracking captures every exception with the context needed to reproduce it, groups the repeats, and alerts a person when something new appears or a known error spikes. Alerts reach a named person by a channel matched to severity; everything else goes to a dashboard and a weekly review. The measure of the whole setup is simple: how often does a user report a problem before the team already knew? It should be close to never.
What is watched
| Area | What | How | Alert when |
|---|---|---|---|
| Availability | Key pages and endpoints respond correctly from several locations | External uptime checks every minute | Down or degraded for more than a minute |
| Errors | Every exception, with request, user, release, stack trace, grouped | Error tracking in the application | A new error type; a known one spiking; an error on a critical flow |
| Performance | Response times by endpoint and screen; database query times; queue delays | Application performance monitoring, real-user timings | Percentiles above budget; a step change after a release |
| Business signals | Orders, sign-ups, submissions, payment failures, job backlog | Metrics from the application, compared with the usual pattern | Outside the normal range for the hour and day |
| Infrastructure | Database load, storage, worker health, certificate expiry | Provider metrics | Thresholds; expiry within days |
| Security | Failed logins, permission changes, unusual access | Audit log and security logging | Volume or pattern anomalies |
Making it useful
- Instrument from day one: error tracking and performance monitoring in the application before the first user.
- Tag every event with the release, so a spike after a deploy points at the deploy.
- Capture context, not secrets: request, user identifier, release, breadcrumbs; never passwords, tokens or form contents.
- Define severities and routes: down and payment failures to a phone; new errors on critical flows to chat; the rest to a daily digest.
- Set business-signal baselines from a few weeks of data and alert on deviation.
- Review weekly: what fired, what was acted on, what to tune or remove.
- Track the measure: user-reported issues that monitoring missed.
What you see as the owner
A monthly report with uptime, error trends by release, performance against budgets and business signals, plus any incidents with cause and fix. When something breaks you usually hear about it from your partner with the fix already applied, because monitoring told them before a user did. When a user does report something first, that is logged as a monitoring gap and closed.
What this means for you
Insist that your application is instrumented from the first day: uptime checks, error tracking with grouping and context, performance monitoring against budgets, business signals with baselines, alerts routed by severity to named people, and a weekly review. Then track one number: problems users reported before the team knew. Driving it towards zero is what monitoring is for.
Frequently asked questions
What is the difference between monitoring and error tracking?
Monitoring watches the system from outside and above: is it up, is it fast, are the business numbers normal. Error tracking watches from inside: every exception the code raises, with the request, the user, the release and the stack trace, grouped so a thousand repeats are one issue. Together they answer both whether something is wrong and exactly what.
How do we avoid drowning in alerts?
Alert on change, not on occurrence: a new error type, an error rate above a threshold, a business metric outside its normal range, the site down. Route by severity: phone for down, chat for high, digest for the rest. Review weekly and remove alerts nobody acted on. A team that receives dozens of alerts a day stops reading them, and the real one is missed.
What business signals should be monitored?
The ones that would tell you the application is failing its purpose even if no error is raised: orders per hour against the usual pattern, sign-ups, form submissions, payment failures, job queue length. A checkout that silently stops converting raises no exception; a business signal catches it within the hour.