Error reports show minified code: make stack traces readable with source maps

Why the trace is unreadable

A browser application is usually bundled and minified before it is deployed, so the stack trace an error produces names single-letter functions and line one of a very long file. An error tracker can show the original code only if it has a source map that connects the minified lines back to your files. Without one, the report says that something failed and gives you almost nothing to act on. Sentry's documentation describes the benefit simply: uploaded source maps let it show the exact line of code that caused the error. Start by looking at a recent error and asking whether the file and line shown are lines you recognise from your source.

• Check one real or test event for the file name and line shown.
• Note which application build produced it and which environment it came from.

How the tracker matches a map to an event

By default Sentry links source maps to events by injecting a Debug ID into your build output, so the code that runs carries an identifier that matches the uploaded map. The documentation says to generate and upload maps for production builds, not development ones, and offers a setup wizard, plugins for the common bundlers and a command-line tool for other toolchains. It also points to older approaches that leave your build output unchanged, which have their own page; read that page for how those maps are matched. Whichever method you use, the deployed code and the uploaded maps have to carry the same linking information, and a mismatch there is a likely reason a trace stays minified.

• Confirm which matching method your build uses: injected Debug IDs or a release name.
• Confirm the upload happens in the same pipeline step as the production build, not as a manual extra.

Check the deployed bundle, not your laptop's build

The usual faults are all about the gap between what you built and what you deployed. The documentation says that if the deployed code lacks Debug IDs, the setup has not been part of the production build, and you should rerun it and make sure the build is a production one. It also says maps must have been uploaded before the errors occurred, so an error raised before the upload finished will stay unreadable. A second pipeline that builds the deployed code differently from the one that uploads the maps produces the same symptom. Look at the files actually served: do they carry the identifier that the tracker expects?

• Compare the identifier in the served file with the one the tracker shows for the uploaded maps.
• Check upload order in the deploy pipeline: maps first, then the release goes live.

Prove it with a deliberate error, and how the paid job is accepted

Do not wait for a real failure to find out. Raise a deliberate test error from a production-style build in a non-production environment and read the stored event. Set a release value as well, because Sentry uses releases to predict the commit that caused an issue and to flag a regression when a resolved issue returns in a newer release. The error-tracking setup job proves exactly this: a test error from a built artefact appears with a readable trace showing file and line, with the release and environment recorded, filtered of sensitive fields and followed by an alert in the channel you named. You create and hold the tracker account and any build token, and you set the production values. Send the stack in general terms and the notification channel first; send no tokens.