Source maps not resolving: get readable stack traces back
Your JavaScript errors show minified frames like a.js:1:48213 instead of your source files. Nine times out of ten, the release strings do not match.
What this looks like
An error arrives from the browser, but the stack trace points into a minified bundle — one long line, mangled function names, useless column numbers. You uploaded source maps, yet the frames stay unreadable. AllStak resolves frames using maps uploaded for the exact release string the event carries; any mismatch and the maps are simply never consulted.
The second-biggest cause is path mismatch: the maps were uploaded for the right release, but the file paths they were registered under do not line up with the URLs the browser actually loaded the bundles from — so the frame lookup misses.
Common root causes
Release string mismatch
The release set in SDK init (e.g. release: process.env.NEXT_PUBLIC_RELEASE) differs from the release the maps were uploaded under — even a v prefix or a short vs full commit SHA breaks the match.
No release set at all
If the SDK sends events without a release, there is nothing to match uploaded maps against. The release option must be set in init for source map resolution to work.
Path / URL misalignment
Map files must be registered under paths that align with the URLs of the served bundles. A CDN prefix, hashed filenames, or a different public path between build and deploy all cause lookups to miss.
New deploy, old maps
Every deploy that changes the bundles is a new release and needs a fresh upload. Events from the new bundles cannot resolve against the previous deploy's maps.
Step-by-step diagnosis
Compare what the event carries with what you uploaded — release first, paths second.
- 1
Read the release on a real event
Open a recent minified error in the AllStak dashboard and note the exact release string it arrived with — including any prefix, suffix, or missing value. This is the string your maps must be uploaded under.
- 2
Confirm maps exist for that exact release
Check what release your build pipeline uploaded maps for. v1.4.2 and 1.4.2 are different releases; so are a short and a full commit SHA. The strings must match character-for-character.
- 3
Align the SDK release with the upload
Set the release option in SDK init from the same CI variable your upload step uses (e.g. the commit SHA), so both sides always agree by construction.
- 4
Check path alignment with served URLs
Open the browser network tab and note the URL each bundle loads from. The paths your maps were uploaded under must align with those URLs — adjust the upload paths if a CDN prefix or public path differs.
- 5
Re-upload for the current deploy
If the running bundles changed since the last upload, upload fresh maps for the current release. Existing minified events stay minified; resolution applies to events arriving after the maps for their release exist.
- 6
Trigger a fresh error and verify
Throw a test error from the deployed app and confirm the new event shows original file names and line numbers. If it does, wire the upload into CI so it happens on every deploy.
Prevent it from recurring
- Derive the release from one CI variable (commit SHA or version) used by both SDK init and the map upload.
- Make map upload a required CI step on every frontend deploy — never a manual afterthought.
- After each deploy, check one new error resolves to source before closing the release.
- Keep generating source maps in production builds even if you do not serve them publicly — upload them to AllStak instead.
Still stuck?
If the release strings match and the paths align but frames still come back minified, email [email protected] with your project name, the release string, and a link to one affected event — we can check what the resolver saw. The AllStak status page covers any platform-side processing issues.
Frequently asked questions
Will old minified events become readable after I upload maps?
Resolution applies to events for releases that have maps. Events that arrived as minified frames before maps existed for their release remain as captured — trigger a fresh error to verify the fix.
Do I need to upload maps on every deploy?
Yes, whenever the bundles change. Each deploy should set a new release in SDK init and upload the matching maps — that is why automating it in CI is the only reliable setup.
What should I use as the release string?
Anything unique per deploy that both the SDK and the upload step can read — most teams use the git commit SHA or a package version like [email protected] from a CI variable.
Does serving .map files publicly replace uploading?
Upload the maps to AllStak for the matching release — that is what resolution uses. You can then keep your production .map files private, which most teams prefer.
Explore more
Capabilities
By framework
Compare
Readable stack traces, every deploy
Set one release variable, upload maps from CI, and every browser error points at your real source. Start free.