Troubleshooting

If you set up the Sentry SDK and it's not sending any data to Sentry:

• Check that you have configured a DSN and that you are passing it to the dsn option in Sentry.init().

  If you are using environment variables to pass the DSN, make sure the environment variables are set in all relevant environments. Additionally, if you are using environment variables inside a framework, check that the framework will include the environment variables in your bundle. Often this means you will have to prefix your environment variables with special prefixes defined by your framework (NEXT_PUBLIC_ in Next.js, NUXT_ in Nuxt, VITE_ for Vite projects, REACT_APP_ for Create React App, ...).

• Check that you have disabled any ad-blockers.

• Set debug: true in the Sentry.init() options and observe your console output when you start your application. The SDK may tell you why it is not sending any data.

• Check the Stats and Suscription pages in Sentry. You may have ran out of quota.

If you update your Sentry SDK to a new major version, you might encounter breaking changes that need some adaption on your end. Check out our migration guide to learn everything you need to know to get up and running again with the latest Sentry features.

You can view the JSON payload of an event to see how Sentry stores additional data in the event. The shape of the data may not exactly match the description.

For more details, see the full documentation on Event Payload.

maxValueLength has a default value of 250, but you can adjust this value according to your needs if your messages are longer. Please note that not every single value is affected by this option.

When using ESM, by default all packages are wrapped under the hood by import-in-the-middle. import-in-the-middle has compatibility issues with some packages and can throw errors in these situations.

Check out the ESM Troubleshooting Instrumentation section for more information.

When you include and configure Sentry, our JavaScript SDK automatically attaches global handlers to capture uncaught exceptions and unhandled promise rejections. You can disable this default behavior by changing the onunhandledrejection option to false in your GlobalHandlers integration and manually hook into each event handler, then call Sentry.captureException or Sentry.captureMessage directly.

You may also need to manage your configuration if you are using a third-party library to implement promises. Also, remember that browsers often implement security measures that can block error reporting when serving script files from different origins.

If you’re seeing errors with the message “Non-Error exception (or promise rejection) captured with keys: x, y, z.”, this happens when you a) call Sentry.captureException() with a plain object, b) throw a plain object, or c) reject a promise with a plain object.

You can see the contents of the non-Error object in question in the __serialized__ entry of the “Additional Data” section.

To get better insight into these error events, we recommend finding where the plain object is being passed or thrown to Sentry based on the contents of the __serialized__ data, and then turning the plain object into an Error object.

If you're using the Vite Bundler and a Sentry NPM package, and you see the following error:

Error: Could not resolve './{}.js' from node_modules/@sentry/utils/esm/index.js

This might be because the define option in your Vite config is string-replacing some variable used by the Sentry SDK, like global, which causes build errors. Vite recommends using define for CONSTANTS only, and not putting process or global into the options. To fix this build error, remove or update your define option, as shown below:

export default defineConfig({
   build: {
     sourcemap: true
   },
-  define: {
-    global: {}
-  },
   plugins: [react()]
})

If you're getting build errors when using any of the JavaScript SDKs mentioning something along the lines of "Cannot find module diagnostics_channel", try to configure your build tool to either externalize or ignore the diagnostics_channel module. The Sentry Node.js SDK uses this built-in module to instrument Node.js fetch requests. Some older Node.js versions do not have the diagnostics_channel API, which may lead to build errors when attempting to bundle your code.

Most bundlers have an option to externalize specific modules (like diagnostics_channel):

• Externals in Webpack
• External in Vite
• External in esbuild
• External in Rollup

If you're using a custom webpack plugin that utilizes Terser or another minifier, you might encounter build errors due to a known webpack bug. This issue has been fixed in webpack version 5.85.1 and later.

For more details about this issue, see webpack/terser-plugin build errors.

When using pnpm, you might encounter errors related to packages that can't be external, particularly with packages like import-in-the-middle and require-in-the-middle. These errors typically occur due to pnpm's strict dependency management and hoisting behavior.

While adding these packages as direct dependencies might remove the warning messages, it often doesn't resolve the underlying functionality issues:

pnpm add import-in-the-middle require-in-the-middle

As a workaround, create or modify .npmrc in your project root:

shamefully-hoist=true