Legacy Uploading Methods

Learn about how to upload source maps with older SDKs and Sentry tools.

Sentry moved to a new process for handling source maps. We call this process "source mapping with debug IDs".

This process requires you to use updated Sentry dependencies. We know this isn't always possible, so this page explains how to upload source maps without debug IDs.

Use the guide on this page if you're using one of the following:

JavaScript SDK version 7.46.0 or lower
@sentry/webpack-plugin package version 1.x or lower
sentry-cli version 2.16.1 or lower
Sentry self-hosted or single-tenant on version 23.6.1 or lower

If all of your Sentry dependencies are on more up-to-date versions than in the list above, we recommend using the regular Source Maps guide.

If you're using one or more of these older versions of the tools, you can still upload source maps; however, the process will be different. Instead of using debug IDs, you'll use Releases to match an event's stack frame with its corresponding minified source and source map file (known as artifacts).

To use this guide, scroll down to the section that corresponds to the tooling you're using, and follow the steps in that section:

sentry-cli
Sentry webpack plugin Version 1.x
Sentry Bundler Plugins on Version 2.x

The final "Verify Artifacts Were Uploaded" section applies to each type of tooling.

To match events with the correct release, you must provide a release property in the SDK options:

Copied

Sentry.init({
  // This value must be identical to the name you give the release that you
  // create below using `sentry-cli`.
  release: "<release_name>",
});

You must first create a release with sentry-cli. The release name must be unique within your organization:

Copied

sentry-cli releases new <release_name>

Next, upload your artifacts (minified sources and source maps):

Copied

sentry-cli sourcemaps upload --release=<release_name> /path/to/directory

Source maps work best with organization-scoped auth tokens. If you are using an old self-hosted Sentry version that doesn't yet support org-based tokens or you're using a different type of Sentry auth token, you'll need to additionally specify your org slug in your sourceMapsUploadOptions:

astro.config.mjs

Copied

export default defineConfig({
  integrations: [
    sentry({
      // Other Sentry options
      sourceMapsUploadOptions: {
        project: "example-project",
        org: "example-org",
        authToken: process.env.SENTRY_AUTH_TOKEN,
      },
    }),
  ],
});

Assuming you have the @sentry/webpack package installed on version 1.x, you can learn more on how to configure the plugin in the Sentry webpack plugin v1 documentation.

Example:

webpack.config.js

Copied

const SentryWebpackPlugin = require("@sentry/webpack-plugin");

module.exports = {
  // ... other config above ...

  devtool: "source-map", // Source map generation must be turned on
  plugins: [
    new SentryWebpackPlugin({
      org: "example-org",
      project: "example-project",

      // Specify the directory containing build artifacts
      include: "./dist",

      // Auth tokens can be obtained from
      // https://sentry.io/orgredirect/organizations/:orgslug/settings/auth-tokens/
      authToken: process.env.SENTRY_AUTH_TOKEN,

      // Optionally uncomment the line below to override automatic release name detection
      // release: process.env.RELEASE,
    }),
  ],
};

The Sentry webpack plugin will automatically inject a release value into the SDK so you must either omit the release option from Sentry.init or make sure Sentry.init's release option matches the plugin's release option exactly:

Copied

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",

  // When using the plugin, either remove the `release`` property here entirely or
  // make sure that the plugin's release option and the Sentry.init()'s release
  // option match exactly.
  // release: "my-example-release-1"
});

If you're using

Sentry self-hosted or single-tenant on version 23.6.1 or lower
or the Sentry JavaScript SDK on version 7.46.0
or esbuild with splitting: true

you'll need to configure the bundler plugins with the release.uploadLegacySourcemaps option.

This applies when using the following packages on version 2.x and above:

@sentry/webpack-plugin
@sentry/vite-plugin
@sentry/esbuild-plugin
@sentry/rollup-plugin

Example of using the release.uploadLegacySourcemaps option:

webpack.config.js

Copied

const { sentryWebpackPlugin } = require("@sentry/webpack-plugin");

module.exports = {
  // ... other config above ...

  devtool: "source-map", // Source map generation must be turned on
  plugins: [
    sentryWebpackPlugin({
      org: "example-org",
      project: "example-project",

      // Auth tokens can be obtained from your User Settings
      // and need `project:releases` and `org:read` scopes
      authToken: process.env.SENTRY_AUTH_TOKEN,

      release: {
        uploadLegacySourcemaps: {
          paths: ["."],
          ignore: ["./node_modules"],
        },
      },
    }),
  ],
};

The Sentry bundler plugins will automatically inject a release value into the SDK so you must either omit the release option from Sentry.init or make sure Sentry.init's release option matches the plugin's release.name option exactly:

Copied

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",

  // When using one of the plugins, either remove the `release`` property here entirely or
  // make sure that the plugin's `release.name` option and the Sentry.init()'s release
  // option match exactly.
  // release: "my-example-release-1"
});

If you followed all of the steps above but still have issues setting up source maps using the legacy method this section will try to help troubleshoot your setup.

To troubleshoot your source maps set up, you can either:

Use our automated verification tool inside sentry-cli, or
Follow the manual steps listed below

To use the automated verification process, install and configure the Sentry Command Line Interface. Then, use the sourcemaps explain command, calling it with the relevant event ID, found in the top-left corner of the Issue Details page in sentry.io.

Note

The sourcemaps explain command requires an auth token with the following scopes: project:admin, release:admin, event:read, and organization:read. We recommend creating an internal integration token over a personal token.

For example, "Event ID: c2ad049f":

Copied

sentry-cli sourcemaps explain c2ad049fd9e448ada7849df94575e019

The CLI output should give you useful information about what went wrong with your source maps setup.

For uploaded source maps to be located and applied, the release needs to be created by the CLI or API (and the correct artifacts uploaded with it), and the name of that newly-created release needs to be specified in your SDK configuration.

To verify this, open up the issue from the Sentry UI and check if the release is configured. If it says "not configured" or "N/A" next to Release on the right hand side of the screen (or if you do not see a release tag in the list of tags), you'll need to go back and tag your errors. If this is properly set up you'll see "Release: my_example_release".

Once your release is properly configured and issues are tagged, you can find the artifacts uploaded to Sentry by navigating to [Settings] > Projects > Select your project > Source Maps.

Additionally, make sure all of the necessary files are available. For Sentry to de-minify your stack traces you must provide both the minified files (for example, app.min.js) and the corresponding source maps. In case the source map files do not contain your original source code (sourcesContent), you must additionally provide the original source files. Alternatively, sentry-cli will automatically embed the sources (if missing) into your source maps.

Some CDNs automatically strip comments from static files, including JavaScript files. This can have the effect of stripping your JavaScript file of its sourceMappingURL directive, because it is considered a comment. For example, CloudFlare has a feature called Auto-Minify which will strip sourceMappingURL if it is enabled.

Double-check that your deployed, final JavaScript files have sourceMappingURL present.

Whenever you are using a distribution identifier (the dist configuration option in the SDK), the same value has to be used during source map upload. Conversely, if your source maps are getting uploaded with a dist value, the same value must be set in your SDK. To add a dist value to your uploaded source maps, use the --dist flag with sentry-cli or the dist option in our Sentry Bundler Plugins (like for example @sentry/webpack-plugin). To set the dist value in the SDK, use the dist option in your Sentry.init().

To verify that the distribution has been set correctly in the SDK, open an issue in the Sentry UI and check that the dist tag is present. For artifacts, go to the Source Maps page in project settings, choose the release shown on the event you just checked, and verify that the dist value (in the small oval next to the upload time) matches that on the event.

If you've uploaded source maps and they aren't applying to your code in an issue in Sentry, take a look at the JSON of the event and look for the abs_path to see exactly where we're attempting to resolve the file - for example, http://localhost:8000/scripts/script.js (abs_path will appear once for each frame in the stack trace - match this up with the file(s) that are not deminified.). A link to the JSON view can be found at the top of the issue page next to the date the event occurred. The uploaded artifact names must match these values.

If you have dynamic values in your path (for example, https://www.site.com/{some_value}/scripts/script.js), you may want to use the rewriteFrames integration to change your abs_path values.

If your sourceMappingURL comment is similar to:

Copied

// -- end script.min.js (located at http://localhost:8000/scripts/script.min.js)
//# sourceMappingURL=script.min.js.map

An example sentry-cli command to upload these files correctly would look like this (assuming you're in the /scripts directory, running your web server from one directory higher, which is why we're using the --url-prefix option):

Copied

sentry-cli sourcemaps upload --url-prefix '~/scripts' .

This command uploads all JavaScript files in the current directory. The Artifacts page in Sentry should now look like:

Copied

~/scripts/script.js
~/scripts/script.min.js
~/scripts/script.min.js.map

Alternately you can specify which files to upload. For example:

Copied

sentry-cli sourcemaps upload --url-prefix '~/scripts' script.min.js script.min.js.map

You can also upload it with the fully qualified URL. For example:

Copied

sentry-cli sourcemaps upload --url-prefix 'http://localhost:8000/scripts' .

You can alternately use our API to upload artifacts, following the same naming convention explained here.

Copied

curl -X POST \
  https://sentry.io/api/0/organizations/ORG_SLUG/releases/VERSION/files/ \
  -H 'Authorization: Bearer AUTH_TOKEN' \
  -H 'content-type: multipart/form-data' \
  -F file=@script.min.js.map \
  -F 'name=~/scripts/script.min.js.map'

The ~ is used in Sentry to replace the scheme and domain. It is not a glob!

http://example.com/dist/js/script.js will match ~/dist/js/script.js or http://example.com/dist/js/script.js

but will NOT match ~/script.js.

It's not uncommon for a web application to be accessible at multiple origins. For example:

Website is operable over both https and http
Geolocated web addresses: such as https://us.example.com, https://eu.example.com
Multiple static CDNs: such as https://static1.example.com, https://static2.example.com
Customer-specific domains/subdomains

In this situation, identical JavaScript and source map files may be located at two or more distinct origins. In this situation we recommend using our special tilde (~) prefix on paths.

So for example, if you have the following:

You can upload using the URL of ~/js/app.js. This will tell Sentry to ignore the domain and use the artifact for any origin.

Additionally you can also upload the same file under multiple names. Under the hood Sentry will deduplicate these.

The ~ prefix tells Sentry that for a given URL, any combination of protocol and hostname whose path is /js/app.js should use this artifact. Use this method only if your source/source map files are identical at all possible protocol/hostname combinations. Sentry will prioritize full URLs over tilde prefixed paths, if found.

The sourceMappingURL comment on the last line of your bundled or minified JavaScript file tells Sentry (or the browser) where to locate the corresponding source map. This can either be a fully qualified URL, a relative path, or the filename itself. When uploading artifacts to Sentry, you must name your source map files with the value the file resolves to.

That is, if your file is similar to:

Copied

// -- end script.min.js
//# sourceMappingURL=script.min.js.map

and is hosted at http://example.com/js/script.min.js, then Sentry will look for that source map file at http://example.com/js/script.min.js.map. Your uploaded artifact must therefore be named http://example.com/js/script.min.js.map (or ~/js/script.min.js.map).

Or, if your file is similar to:

Copied

//-- end script.min.js
//# sourceMappingURL=https://example.com/dist/js/script.min.js.map

then your uploaded artifact should also be named https://example.com/dist/js/script.min.js.map (or ~/dist/js/script.min.js.map).

Finally, if your file is similar to:

Copied

//-- end script.min.js
//# sourceMappingURL=../maps/script.min.js.map

then your uploaded artifact should be named https://example.com/dist/maps/script.min.js.map (or ~/dist/maps/script.min.js.map).

###Verify Artifacts Are Uploaded Before Errors Occur

Sentry expects that source code and source maps in a given release are uploaded to Sentry before errors occur in that release.

If you upload artifacts after an error is captured by Sentry, Sentry will not go back and retroactively apply any source annotations to those errors. Only new errors triggered after the artifact was uploaded will be affected.

We maintain an online validation tool that can be used to test your source maps against your hosted source: sourcemaps.io.

Alternatively, if you are using Sentry CLI to upload source maps to Sentry, you can use the --validate command line option to verify your source maps are correct.

If you find that Sentry is not mapping filename, line, or column mappings correctly, you should verify that your source maps are functioning locally. To do so, you can use Node.js coupled with Mozilla's source-map library.

First, install source-map globally as an npm module:

Copied

npm install -g source-map

Then, write a Node.js script that reads your source map file and tests a mapping. Here's an example:

Copied

var fs = require("fs"),
  path = require("path"),
  sourceMap = require("source-map");

// Path to file that is generated by your build tool (webpack, tsc, ...)
var GENERATED_FILE = path.join(".", "app.min.js.map");

// Line and column located in your generated file (for example, the source
// of the error from your minified file)
var GENERATED_LINE_AND_COLUMN = { line: 1, column: 1000 };

var rawSourceMap = fs.readFileSync(GENERATED_FILE).toString();
new sourceMap.SourceMapConsumer(rawSourceMap).then(function (smc) {
  var pos = smc.originalPositionFor(GENERATED_LINE_AND_COLUMN);

  // You should see something like:
  // { source: 'original.js', line: 57, column: 9, name: 'myfunc' }
  console.log(pos);
});

If you have the same (incorrect) results locally as you do via Sentry, double-check your source map generation configuration.

For an individual artifact, Sentry accepts a max filesize of 40 MB.

Often users hit this limit because they are transmitting source files at an interim build stage. For example, after your bundler has combined all your source files, but before minification has taken place. If possible, send the original source files.

The Sentry API currently only works with source maps and source files that are uploaded as plain text (UTF-8 encoded). If the files are uploaded in a compressed format (for example, gzip), they will be not be interpreted correctly.

If you are using sentry-cli to upload your artifacts, starting with version 2.4.0 you can add the --decompress flag to your sourcemaps upload or files upload commands.

Sometimes build scripts and plugins produce pre-compressed minified files (for example, webpack's compression plugin). In these cases, you'll need to disable such plugins and perform the compression after the generated source maps/source files have been uploaded to Sentry.

If you're running a self-hosted version of Sentry, you can verify that the symbolicator service/container is operating normally by checking the container's logs.

Sentry does source map calculation in its workers. This means the workers need access to the files uploaded through the front end. Double check that the cron workers and web workers can read/write files from the same disk.

The Sentry Node.js SDK generally works well with the source-map-support package if you don't already have source maps uploaded to Sentry.

If you are uploading source maps to Sentry or if you are using a Sentry SDK in the browser, your code cannot use the source-map-support package. source-map-support overwrites the captured stack trace in a way that prevents our source map processors from correctly parsing it.

Troubleshooting Source Maps

What are Artifact Bundles

Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").

How to contribute | Edit this page | Create a docs issue | Get support

Account Settings

Organization Settings

Product Walkthroughs

Pricing & Billing

Sentry CLI

Sentry API

Security, Legal, & PII

Concepts & Reference

Legacy Uploading Methods

Learn about how to upload source maps with older SDKs and Sentry tools.

Note