Sentry: minified stack traces, source maps not applying

TL;DR

Run npx @sentry/wizard@latest -i sourcemaps and make sure you are shipping a production build. Dev builds typically do not generate maps for upload. - "Source maps not applying": verify artifacts are uploaded before errors occur. SENTRY\ALLOW\FAILURE was set so a failed upload did not block CI, and nobody noticed uploads failing for weeks. Auth token fixed but the upload step still points at the wrong org/project.

When to use

You are seeing this: Issues show minified frames (a.b.c) with no source context, even though you upload source maps. Use this skill when you run into "Sentry: minified stack traces, source maps not applying".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

The symptom

Issues show minified frames (a.b.c) with no source context, even though you upload source maps.

How linking works now

Sentry injects Debug IDs into your build output and matches uploaded artifacts by those IDs. The old filename-matching heuristics are the fallback, not the mechanism. If the deployed bundle has no Debug IDs, uploads cannot attach to anything.

The doc's own troubleshooting strings

• "Sentry not part of build pipeline": your deployed code is missing Debug IDs. Run npx @sentry/wizard@latest -i sourcemaps and make sure you are shipping a production build. Dev builds typically do not generate maps for upload.
• "Source maps not applying": verify artifacts are uploaded before errors occur. Uploads that land after the error are useless for that error.

The ordering rule

Upload must happen in the build, before deploy, and the release/dist of the upload must match the release/dist of the running code. Common breaks:

1. Upload runs in CI but the deploy ships a different build (rebuilt Docker layer, different commit).
2. SENTRY_ALLOW_FAILURE was set so a failed upload did not block CI, and nobody noticed uploads failing for weeks.
3. Auth token fixed but the upload step still points at the wrong org/project.

Confirmation and fix

Open an issue, check a frame, and look for the debug ID. Then check Project Settings > Source Maps (or Debug Files) for an artifact with that ID. Missing ID on the event means the build did not inject; missing artifact means the upload did not land. Fix the build step, redeploy, and confirm the next error resolves to real source lines.

Researched against live Sentry docs 2026-09-26. The JS source maps page (docs.sentry.io/platforms/javascript/sourcemaps/) documents: Sentry links source maps by injecting Debug IDs into build output; the wizard (npx @sentry/wizard@latest -i sourcemaps) configures generation and upload; source maps are only generated and uploaded during production builds; and the troubleshooting strings Sentry not part of build pipeline (deployed code missing Debug IDs, fix by running the wizard and ensuring a production build) and Source maps not applying (verify artifacts are uploaded before errors occur).