Skip to main content
When your JavaScript application is bundled and minified for production, stack traces become nearly unreadable — file names like bundle.min.js and line numbers that point to a single concatenated line tell you nothing. Superlog uses uploaded source maps to symbolicate those stack traces, replacing minified references with the original file paths and line numbers from your source code.

How it works

After you upload a source map for a given release, Superlog matches it against incoming error events using the release, dist, debugId, and mapFile fields you provided at upload time. When a match is found, stack frames are rewritten in-place before they appear in incidents, logs, and AI investigations — so your team always sees original source locations without any manual lookup.
Source maps are stored securely and are never exposed publicly. Only authenticated members of your organization can access symbolication results.

Upload endpoint

Source maps are uploaded to the management API using your organization API key:

Upload payload

sourceMapHash and sourceMapBytes must exactly match the sourceMap content you provide. Superlog validates both before storing the artifact and will reject the upload if they differ.

Node.js upload example

The following script computes the required hash and byte length, then posts the source map to Superlog. Run it as part of your build pipeline after bundling.

CI/CD automation

Add the upload script as the last step in your build job, after the bundle is produced but before deployment. Pass RELEASE as your Git SHA ($GITHUB_SHA) or semantic version tag to ensure each deployment maps to a unique artifact.
A typical GitHub Actions workflow step looks like this:
For Node.js applications running server-side, set platform: "node" and point mapFile at your compiled server bundle’s map file.