You shipped, and now real users are hitting bugs you never see. To learn how to track errors in production, add an error-tracking SDK, tag releases, upload source maps, and alert on new issues.
This step-by-step guide is one part of the wider topic of error monitoring.
| Setting or fact | Value |
|---|---|
| Error events sent in the example SDK config | 100% of errors |
| Performance traces sampled in the example config | 10% of transactions |
| Collector OTLP ports (gRPC and HTTP) | 4317 and 4318 |
| Collector batch processor | 10 seconds timeout, batch size 1024 |
| Sentry exporter request timeout | 30 seconds |
These figures come from Azynth’s Sentry production guide and OneUptime’s Collector guide. They are example settings that can change, so check the source before you rely on them.
Why logs alone miss production errors
A log line says something happened, but it rarely says who was affected or whether anyone noticed. Azynth’s guide shows the typical failure: a payment call throws, the error goes to the console, and it ends up as an “Error buried in logs, no alert, no context“.
An error tracker fills those gaps. The same guide lists what Sentry adds on top of plain logging:
- It aggregates duplicate errors into one issue.
- It shows stack traces with source maps.
- It captures user context and breadcrumbs.
- It alerts when new issues appear.
If you want the full contrast, the guide on error monitoring vs logging covers where each tool fits.
Decide what counts as an error before you start. The Gauzy docs describe a typical integration as capturing these four things:
- Unhandled exceptions
- HTTP 5xx responses
- Slow database queries
- Performance traces
Set up the SDK, environment and release
The setup is short and the order matters. Follow these steps for any language, using the Gauzy docs and Uptrace’s Sentry guide as reference:
- Create a project for your runtime, such as Node.js, and copy its DSN.
- Install the SDK and initialise it as early as possible in your application lifecycle.
- Set the environment to production and set a release value.
- Deploy, send a test message, and confirm it appears in the dashboard.
The release value is what turns a pile of errors into a useful timeline. According to OneUptime’s guide, Sentry uses release information to help identify regressions and show which application versions have the most errors.
Use a version number or, better, the commit SHA from your build. Then every issue can be tied to the deploy that introduced it.
Make stack traces readable with source maps
Browser code is minified before it ships. Uptrace’s guide notes that minified production JavaScript turns browser stack traces into unreadable references, and Azynth’s guide says the same: without source maps, stack traces show minified code.
Fixing this is a build-pipeline task:
- Make your bundler emit source maps, since the upload plugin cannot send files that do not exist.
- Upload them from your build or CI step, not by hand.
- Keep the upload token out of the browser bundle, because it is a build-time secret.
- Do not serve the maps to visitors; one Next.js example sets a flag so source maps are not exposed to users.
Uptrace also explains how matching works: the plugin injects a unique debug ID into each minified file and its source map. The SDK then reports that ID with every error, so the right map is picked for the right build.
Add context, then cut the noise
A stack trace shows where code failed, not why. Attach context so you can reproduce the problem: the user ID, tags for filtering, and breadcrumbs. Azynth’s guide describes breadcrumbs as the trail of events before an error.
Be careful with personal data. The Uptrace example uses a beforeSend hook to remove sensitive data from errors before they leave the app, and you should do the same for emails and tokens.
Noise is the next problem. You can drop errors you cannot act on, such as the browser warnings “ResizeObserver loop limit exceeded” and “Non-Error promise rejection captured”, which Azynth’s example ignores.
The same example sets sampling so that all errors are kept but only a slice of performance data is. It uses 100% of errors and 10% of transactions, which keeps volume and cost under control without hiding failures.
Finally, check grouping. Sentry groups similar errors by default and lets you control grouping with fingerprints, so one noisy bug does not bury the quiet ones.
Alert on new, returning and spiking issues
Tracking without alerts just moves the logs somewhere prettier. Azynth’s guide shows three useful alert conditions:
- A new issue appears.
- A regression, meaning an issue reappears after being resolved.
- A spike in event frequency.
Route these to a channel your team actually reads. Start with few rules and tune them using the advice on how to reduce alert fatigue, because a flooded channel gets muted.
Use OpenTelemetry if it is already in your stack
If your services already emit OpenTelemetry data, you do not have to start over. Sentry’s OpenTelemetry page says you set the OTEL_EXPORTER_OTLP_ENDPOINT environment variable, add your auth header, and you are done.
The same page says that when a Sentry SDK and OTel instrumentation run in the same service, they share the same trace ID automatically. Errors then link to the exact span where they happened.
If you route data through a Collector, the examples in OneUptime’s guide listen on ports 4317 and 4318. They batch with a 10 second timeout and a batch size of 1024, and they give the Sentry exporter a 30 second request timeout.
Two limits are worth knowing. The guide recommends filtering traces to errors and slow operations in production to reduce noise and cost. It also says the Collector does not create Sentry sessions from traces by itself, since release-health data usually comes from the SDKs.
Frequently asked questions
Should I send every error to the tracker?
Show answer
Usually yes for errors, and no for performance data. Azynth’s example keeps 100% of errors but samples 10% of transactions, then filters known noise.
Why are my production stack traces unreadable?
Show answer
Your code is almost certainly minified, and the tracker has no source maps to translate it. Emit maps in your build and upload them in CI, as described in Uptrace’s guide.
Can I use OpenTelemetry without a vendor SDK?
Show answer
Sentry’s own page says you can point any OpenTelemetry SDK directly at its OTLP endpoint, with no Sentry SDK or Collector needed. That is a vendor claim, so test it with your stack. See the Sentry page for details.
How do I keep sensitive data out of error reports?
Show answer
Filter events before they are sent. The Uptrace example removes user email in a beforeSend function, and you can extend that idea to any field you should not store.
