Source maps

Production JavaScript is minified, so a captured stack trace points at your built bundle — app.min.js:2:14501 — which tells you nothing. Upload the source maps from your build and error.page turns those frames back into your original files, functions, and line numbers.

Source maps are a Business feature.

How it fits together

1. Tell the SDK which build is running. Set the release option so every error records the version that produced it:

   ErrorPage.init({
     projectId: 'ep_live_xxx',
     slug: 'my-store',
     release: '1.4.2'          // or a git sha — anything stable per deploy
   });
   

2. Upload the maps for that same release. Either from the dashboard (Source Maps in the sidebar) or from your CI/CD pipeline.

3. View the incident. Stack frames from that release are resolved to your original source automatically.

We match a stack frame's file to its map by filename — a frame in https://cdn.example.com/assets/app.min.js is resolved by the map you uploaded for app.min.js. Host and query string are ignored.

Uploading from CI/CD

Add this to your deploy pipeline after your build produces the .map files. It authenticates with your project's secret key (never the public key):

curl -X POST https://error.page/api/v2/sourcemaps \
  -H "X-Project-Key: $EP_PROJECT_KEY" \
  -H "X-Secret-Key: $EP_SECRET_KEY" \
  -F "release=$RELEASE" \
  -F "maps[]=@dist/app.min.js.map" \
  -F "maps[]=@dist/vendor.min.js.map"

Re-uploading a map for the same release and bundle replaces the previous one.

Privacy & storage

Source maps reveal your original source, so they are stored on a private disk and are never publicly downloadable — they are only ever read server-side to resolve a stack trace for someone who can already see the incident. Pass your secret key as a CI secret; don't commit it.

Tip: keep releases short and stable (a semver tag or the git sha). The value you pass to the SDK's release and to -F release= must match exactly.