Source Maps & Releases for Error Tracking

Quick answer: how do I get readable JavaScript stack traces?

Generate production source maps, upload them to Telebugs during your build, and make sure the uploaded artifacts can be matched to the error event. Modern Sentry CLI workflows usually do this by injecting Debug IDs into the built JavaScript and source map files, then uploading the build directory. Release and dist values can also be used when your deploy process needs that extra specificity.

export SENTRY_URL=https://your-telebugs-instance.example/
export SENTRY_AUTH_TOKEN=your-telebugs-api-key
export SENTRY_ORG=telebugs
export SENTRY_PROJECT=your-project

npm run build
sentry-cli sourcemaps inject ./dist
sentry-cli sourcemaps upload ./dist

If you already upload source maps to Sentry, the migration is usually endpoint and token work: point the SDK DSN and Sentry CLI configuration at Telebugs, then send a minified test error and verify that the backtrace resolves.

Why releases and sourcemaps matter

In production, JavaScript and TypeScript are usually bundled and minified. Variable names get shortened, whitespace disappears, and entire files get concatenated. When an error occurs, the stack trace points to line numbers and symbols that no longer exist in your source.

Without sourcemaps, you are left guessing which component, hook, or function actually failed. Debugging turns into archaeology. Releases tie those maps to specific versions of your app so you know exactly which deploy introduced (or fixed) a problem.

This is one of the highest-ROI improvements for frontend and full-stack JavaScript teams. It also helps error grouping, because resolved source frames give the tracker more stable call sites than minified bundle positions.

How Telebugs handles releases and sourcemaps

Telebugs treats releases, source maps, and uploaded artifacts as first-class parts of error tracking. The goal is simple: by the time an engineer opens a production frontend error, the stack trace should point at the original source file, function, and line.

• A source map is a build artifact that maps bundled or minified output back to original JavaScript, TypeScript, JSX, or TSX source.
• A release is a named version of your application, often a semantic version, commit SHA, image tag, or deploy identifier.
• A Debug ID is metadata injected into build artifacts so an event can be matched to the exact minified file and source map that produced it.
• A dist value can distinguish build variants inside one release, such as web, admin, mobile shell, region, or CDN target.
• An artifact bundle is the uploaded set of minified files and source maps that Telebugs can use when resolving frames.

Telebugs supports Sentry CLI based source map workflows, including modern Sentry CLI v3 compatibility. This works for Sentry-compatible SDKs sending JavaScript or TypeScript errors. You keep the instrumentation, breadcrumbs, tags, user context, release values, and build scripts you already rely on, then point the DSN and CLI configuration at Telebugs.

Source map upload workflows

There are three common ways to wire source maps into Telebugs. Pick the one that matches your build process.

Debug ID artifact bundles

This is the modern Sentry CLI style. Run your production build, inject Debug IDs, upload the output directory, and deploy the same files that were injected.

npm run build
sentry-cli sourcemaps inject ./dist
sentry-cli sourcemaps upload ./dist

Sentry's current JavaScript source map docs recommend integrating this into CI/CD so every production deploy uploads matching artifacts. The same principle applies with Telebugs: upload the artifacts produced by the build you are about to deploy.

Release and dist based uploads

If your app already sets release or dist in the Sentry SDK, keep those values identical in the upload command. This is useful when one project has multiple bundles or deploy variants.

export [email protected]

sentry-cli releases new "$RELEASE"
sentry-cli sourcemaps inject ./dist
sentry-cli sourcemaps upload --release="$RELEASE" ./dist

Use --dist when the same release can produce different bundles. The value sent by the SDK must match the value used during upload.

Manual release artifacts

Smaller teams can also create a release in the Telebugs dashboard and attach source map artifacts manually. It is less automated, but it is useful for one-off apps, quick verification, and debugging an existing production build.

Tooling that fits this workflow

The most reliable way is to upload during or right after your production build.

• Sentry CLI works for almost any bundler and is the simplest shared path across frameworks.
• Bundler plugins for Vite, webpack, Rollup, and esbuild can generate and upload artifacts as part of your build.
• TypeScript and custom build scripts work as long as they produce standard .map files and upload the matching output.
• CI/CD systems such as GitHub Actions, GitLab CI, Buildkite, and deploy scripts are the right place to run the upload reliably.

Configure Sentry CLI with SENTRY_URL, SENTRY_AUTH_TOKEN, SENTRY_ORG, and SENTRY_PROJECT, or place the same values in .sentryclirc. Sentry's CLI docs note that SENTRY_URL is the setting used for self-hosted or alternate Sentry-compatible endpoints.

What you gain in practice

The difference is immediate and dramatic for any team shipping minified frontend or full-stack JavaScript.

• Stack traces point to the exact line in your source component or hook instead of a 1-character minified identifier.
• You can click through to the original file in context of the error (or copy the readable frame for your editor).
• Grouping quality improves because Telebugs can see the real call sites before grouping rules run.
• Releases give you a timeline: "this regression appeared in 1.11.3" with the exact sourcemaps for that version.
• No extra agents or sidecars. The same single Telebugs container that ingests errors also serves the map lookup.

Teams using React, Next.js, Vue, Svelte, or plain TypeScript in Node report the biggest wins because their production bundles are heavily transformed.

Source map troubleshooting checklist

If production stack traces are still minified after upload, check the boring details first. Most source map failures come from mismatched build artifacts, missing metadata, or uploading maps from a different build than the one deployed.

Symptom	Likely cause	Fix
Stack frames stay minified	The deployed files do not match the uploaded artifacts.	Run injection, upload, and deploy from the same build output.
Only some files resolve	Not every chunk, route, worker, or lazy-loaded bundle was uploaded.	Upload the whole build directory, including generated chunks and maps.
Release-specific upload does not apply	The SDK release or dist value differs from the upload command.	Use one release string from build through SDK initialization and upload.
Upload works locally but not in CI	Missing auth token, project/org value, or endpoint in the CI environment.	Set SENTRY_URL, SENTRY_AUTH_TOKEN, SENTRY_ORG, and SENTRY_PROJECT in CI.
A new deploy reintroduces unreadable frames	The upload step is manual or optional.	Make source map upload part of the production deployment pipeline.

Sentry's current docs also call out two common checks: production builds must actually generate source maps, and artifacts should be uploaded before the relevant production errors arrive.

When releases and sourcemaps make sense

You need them if you minify or bundle JavaScript/TypeScript that runs in production (browser or server). Almost every modern web or hybrid app does.

They are less critical for pure backend services that ship readable source or for very small internal tools where you can reproduce locally easily. But even then, having them available for the occasional hard production bug is cheap insurance.

If you are already using a Sentry SDK compatible error tracking setup, adding source map support is usually the highest-leverage next step after basic DSN configuration.

How this compares to self-hosted Sentry

The client-side experience is nearly identical because you are using the same SDKs and the same wire format. The difference is on the server side:

• Self-hosted Sentry is a broad platform, while Telebugs keeps source maps and releases inside focused error tracking.
• Telebugs keeps source map and release functionality in the same lightweight self-hosted product as grouping, reports, notifications, notes, and retention.
• No event quotas mean a frontend error storm is a debugging problem, not a surprise per-event bill.
• Setup for this specific feature can reuse the same Sentry CLI and build-pipeline concepts you already know.

Many teams end up running Telebugs because they want Sentry SDK compatibility and source map support without the operational tax of the full self-hosted Sentry stack. For the broader comparison, see Telebugs vs self-hosted Sentry.

Frequently asked questions

Are source maps and sourcemaps the same thing?

Yes. Developers write both "source maps" and "sourcemaps." They refer to the same build artifacts that map minified JavaScript or TypeScript back to the original source code.

Do I need releases to use source maps?

Not always. Modern Debug ID artifact uploads can match source maps without relying only on a release name. Releases are still useful because they tie errors to deploys, versions, commits, and timelines. If you use release or dist values, make sure the SDK and upload command use the same values.

Does Sentry CLI work with Telebugs?

Yes for the Telebugs-supported release and source map workflow. Configure SENTRY_URL to point at your Telebugs instance, use a Telebugs API key as SENTRY_AUTH_TOKEN, and keep your org/project values consistent.

Which bundlers and tools are supported?

Anything that can produce standard .map files and upload them through Sentry CLI or a compatible build integration can fit the workflow. This includes Vite, webpack, Rollup, esbuild, TypeScript, Sentry CLI, and common CI/CD scripts.

Why are my source maps not working?

The most common reasons are mismatched build artifacts, missing Debug IDs, release or dist values that do not match, source maps generated for a different build, or CI missing SENTRY_URL, SENTRY_AUTH_TOKEN, SENTRY_ORG, or SENTRY_PROJECT.

Does this affect error grouping?

Yes, in a good way. When frames resolve back to original source, you get more accurate and stable groups for frontend errors. See the error grouping guide for details.

Should I publish source maps publicly?

No, not unless you deliberately want to. Uploading source maps privately to Telebugs gives you readable stack traces without making original source easier to inspect from a public CDN.

How much storage do source maps use?

It depends on bundle size and how many releases you keep. Telebugs stores artifacts with your error tracking data and can purge them according to retention settings. There are no per-event or per-map fees. Full details in the data retention and compliance guide.

Can I use this with existing Sentry instrumentation?

Yes. Point the DSN at your Telebugs instance and configure Sentry CLI or your build integration to upload artifacts to Telebugs. Your error capture code, breadcrumbs, tags, release values, and user context can keep flowing through the same Sentry SDK payloads.

Ready to see your real source code in production errors?

Read the Telebugs manual for releases and source maps, review pricing, or request a private demo. When you are ready, buy Telebugs and start uploading maps from your next deploy.