How to Do Error Monitoring

Logging answers “what happened.” Error monitoring answers “which errors are hurting users.”

Many early products have no error monitoring. They rely on user screenshots, server logs, and developer intuition. The result is predictable: production errors can happen for days without anyone knowing, a release can introduce a bug that is discovered only after users leave, and frontend blank screens, payment failures, and job exceptions are scattered across different places.

The goal of error monitoring is not to collect every possible error. The goal is to quickly answer:

How many users are affected?
Which release introduced it?
Which code path does the stack trace point to?
Do we have reproduction context?
Should we fix it now or schedule it later?

This article references official materials:

• Sentry Breadcrumbs
• Sentry Releases & Health
• Sentry Troubleshooting Source Maps
• Sentry Create a New Release API
• OpenTelemetry Exceptions
• Grafana Alerting

Error Monitoring Is Not Logging

Logs are process records. Error monitoring is exception aggregation.

Logs may contain thousands of events. Error monitoring groups similar errors into issues and shows occurrence count, affected users, first seen time, last seen time, stack trace, environment, and release.

Use them this way:

Logs: reconstruct the full process
Error monitoring: discover and group exceptions
Metrics: understand overall system health
Alerts: tell you when action is needed

If you only have logs, it is hard to know which error matters most. If you only have error monitoring, you may lack business process details.

Use both together.

Cover Frontend and Backend First

The first step is to connect both frontend and backend.

Frontend should capture:

JavaScript runtime errors
Unhandled promise rejections
Blank screen failures
Asset loading failures
Critical API request failures
Frontend route transition errors

Backend should capture:

Unhandled exceptions
API 5xx responses
Database exceptions
Third-party API exceptions
Background job exceptions
Webhook processing exceptions
Queue consumer exceptions

Backend-only monitoring is not enough. Many user-visible issues happen in the browser and never appear in backend logs.

Frontend-only monitoring is also not enough. Payments, permissions, databases, and jobs fail on the server.

Issue Grouping Matters More Than Single Events

One of the biggest benefits of an error monitoring platform is grouping similar errors into an issue.

A single event tells you “this failed once.” An issue tells you:

How many times it happened
How many users it affected
Whether it increased after a release
Whether it only happens in a browser or region
Whether it is still happening
Whether it was fixed and then regressed

During triage, do not chase every single event. Look at impact first.

An error affecting one internal test account is different from an error blocking 300 paying users from completing payment.

Source Maps Must Work

If you build a frontend app, source maps are critical.

Without source maps, production stack traces may only show minified files and positions:

app.min.js:1:48392

That is barely useful.

With source maps, an error monitoring platform can map production errors back to the original source files, functions, and lines.

Sentry's source map documentation also emphasizes that source code and source maps should be uploaded for the relevant release, usually before errors occur.

Before launch, confirm:

Production build generates source maps
Source maps are uploaded to the monitoring platform
Release version matches the deployed build
Error events de-minify stack traces correctly
Sensitive source files are not publicly exposed

If frontend errors are numerous but stack traces are unreadable, error monitoring loses much of its value.

Release and Environment Must Be Accurate

Every error should include environment and release.

Common environments:

development
preview
staging
production

Release identifiers can be:

Git commit SHA
Semantic version
Build number
Deployment timestamp

Sentry's release documentation explains that releases help identify whether issues were introduced by a deployment and connect errors to commits and deploys.

Without releases, it is hard to answer:

Did this error start after the latest deploy?
Which version introduced it?
Has the fix been released?
Did the error stop after rollback?

Every deployment should include a clear release identifier.

Context Saves More Time Than Stack Traces Alone

The stack trace tells you where the code failed. Context tells you why it failed.

Attach useful context to error events:

user_id
team_id
request_id
route
feature
plan
browser
device
region
release
environment
important business object IDs

Still protect privacy. Do not attach passwords, tokens, or raw private content.

Sentry's Breadcrumbs documentation explains that breadcrumbs can record a trail of events before an issue, such as user actions, requests, route changes, and state changes. This is often essential for reproduction.

A good error event should show:

What the user did first
Which API the system called
Which step failed
What state existed before and after the failure

Some Errors Should Be Ignored

More error events are not always better.

Some noise should be filtered:

Browser extension injection errors
Known crawler errors
Request cancellations caused by user network changes
Occasional third-party script failures
Old browser compatibility issues with no business impact
Local development errors
Health check request errors

Without noise reduction, error monitoring becomes a junk drawer.

But filter carefully. Do not ignore real user errors just because they are annoying. Check impact, user type, and business path before creating filter rules.

Alert Based on Impact

Do not send a notification for every new issue.

Early alert rules can include:

New production error
Affected users exceed a threshold
Critical paths fail: payment, login, signup, upload
Error rate increases after a release
Same error spikes in a short time
Background job fails repeatedly
Webhook fails repeatedly

Grafana Alerting documentation explains that alert rules can use queries, conditions, and notifications across metrics and logs.

The point of alerting is not “shout whenever an error exists.” It is “notify when action is worth taking.”

Errors Need a Workflow

After error monitoring is connected, you still need a handling process.

A simple workflow:

1. New error enters the inbox
2. Confirm whether it is production
3. Check affected users and frequency
4. Check whether it affects a critical path
5. Assign an owner
6. Set priority
7. Link the fix to a release
8. Observe whether it stops or regresses

Without a workflow, the platform fills with unresolved issues and eventually nobody looks at it.

Early on, clean the error inbox weekly. On launch day, after payment changes, login changes, permission changes, and major deployments, check it more often.

Do Not Use Error Monitoring as an Audit System

Error monitoring is not audit logging or product analytics.

It records exceptions and exception context. Do not send every user action, business event, or permission change into error monitoring just to avoid building proper systems.

Use this separation:

Error monitoring: exceptions, stack traces, context, impact
Logs: process records and debugging clues
Audit logs: critical changes and who changed what
Analytics: user behavior and conversion paths
Metrics: system health, trends, thresholds

Clear boundaries make the system easier to maintain.

A Minimum Viable Setup

If you are an indie developer, start with this:

1. Connect error monitoring SDKs on frontend and backend
2. Report only production and preview by default, not development
3. Include release and environment on every deployment
4. Upload frontend source maps
5. Attach user_id, team_id, request_id, and route
6. Give login, payment, upload, webhook, and jobs higher priority
7. Filter obvious invalid noise
8. Alert on new errors and error spikes
9. Clean unresolved issues weekly

This setup is not complicated, but it moves you from “waiting for user reports” to “discovering issues proactively.”

Final Thoughts

Error monitoring turns production exceptions into work items that can be grouped, located, assigned, and verified.

Do not stop at “we installed a tool.” What matters is readable stack traces, enough context, accurate releases, calm alerts, and a workflow with ownership.

Once your product has real users, error monitoring is not an advanced setup. It is infrastructure.

Next, we continue with growth and product judgment: How to Design User Analytics Events.