---
title: "Troubleshooting"
description: "If you need help solving issues with your Sentry JavaScript SDK integration, you can read the edge cases documented below."
url: https://docs.sentry.io/platforms/javascript/guides/cloudflare/troubleshooting/
---

# Troubleshooting | Sentry for Cloudflare

The SDK is not sending any data

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](https://sentry.io/orgredirect/organizations/:orgslug/stats/) and [Subscription](https://sentry.io/orgredirect/organizations/:orgslug/settings/billing/overview/) pages in Sentry. You may have ran out of quota.

Updating to a new Sentry SDK version

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](https://docs.sentry.io/platforms/javascript/guides/cloudflare/migration/v10-to-v11.md) to learn everything you need to know to get up and running again with the latest Sentry features.

Debugging additional data

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](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/).

Max JSON payload size

By default, `maxValueLength` is undefined and nothing is truncated, but you can change this value according to your needs if your messages are longer (for example, to `250`). Please note that not every single value is affected by this option.

Third party promise libraries

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.

Events with 'Non-Error Exception'

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.

Build errors with vite

If you're using the [Vite Bundler](https://vitejs.dev/) and a Sentry NPM package, and you see the following error:

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

This might be because the [`define`](https://vitejs.dev/config/shared-options.html#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:

```javascript
export default defineConfig({
   build: {
     sourcemap: 'hidden'
   },
-  define: {
-    global: {}
-  },
   plugins: [react()]
})
```

Missing module \`diagnostics\_channel\`

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](https://webpack.js.org/configuration/externals/)
* [External in Vite](https://vitejs.dev/config/ssr-options.html#ssr-external)
* [External in esbuild](https://esbuild.github.io/api/#external)
* [External in Rollup](https://rollupjs.org/configuration-options/#external)

Terser plugin build errors

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](https://github.com/getsentry/sentry-javascript/issues/14091).

Spans from waitUntil() or other work after the response are missing

Cloudflare's [`waitUntil()`](https://developers.cloudflare.com/workers/runtime-apis/handlers/fetch/#contextwaituntil) lets work continue after the Worker returns a response. Whether those spans arrive depends on your trace lifecycle.

In transaction mode (`traceLifecycle: "static"`), the SDK snapshots the request transaction when the response is returned, so spans that finish later may be missing. Stream mode, the default since SDK version 11.0.0, sends sampled spans in batches as they finish, which captures deferred work.

If you use transaction mode, remove `traceLifecycle: "static"` or set it to `"stream"`. On SDK version 10, explicitly set `traceLifecycle: "stream"`, which requires `@sentry/cloudflare` version `10.49.0` or newer:

```javascript
export default Sentry.withSentry(
  (env) => ({
    dsn: env.SENTRY_DSN,
    tracesSampleRate: 1.0,
    traceLifecycle: "stream",
  }),
  worker,
);
```

If you need to keep transaction mode, wrap the background work in its own span with `forceTransaction: true`, which records it as a separate transaction. `forceTransaction` isn't available in stream mode.

```javascript
ctx.waitUntil(
  Sentry.startSpan(
    { name: "background.task", op: "task", forceTransaction: true },
    () => updateCacheAndDatabase(),
  ),
);
```

See [Streamed Spans](https://docs.sentry.io/platforms/javascript/guides/cloudflare/tracing/streamed-spans.md) for how streaming changes filtering with `beforeSendSpan` and `ignoreSpans`.

My events have no release, or the wrong one

The SDK resolves the release from the `release` option you pass, then the `SENTRY_RELEASE` environment variable, then the `CF_VERSION_METADATA.id` binding. The first one that is set wins. Reading the binding automatically needs `@sentry/cloudflare` version `10.35.0` or newer; on earlier versions, pass it as the `release` option yourself, as shown at the end of this entry.

If your events carry no release, check that the binding is declared in your wrangler config:

```jsonc
{
  "version_metadata": {
    "binding": "CF_VERSION_METADATA"
  }
}
```

*Other available variations of the above snippet: Toml*

The binding only carries a meaningful version ID on a deployed Worker. In local development the value is [not applicable or accurate](https://developers.cloudflare.com/workers/local-development/), so events from `wrangler dev` or `vite dev` won't match a release in Sentry.

If your events carry a release you didn't expect, something further up the list is set. A `SENTRY_RELEASE` variable left over in your Worker's environment overrides the binding, and an explicit `release` option overrides both.

To pin the release to the Cloudflare version ID no matter what else is set, pass it yourself:

```javascript
Sentry.withSentry(
  (env) => ({
    dsn: "https://<key>@o<orgId>.ingest.sentry.io/<projectId>",
    release: env.CF_VERSION_METADATA?.id,
  }),
  // ...
);
```

If you need additional help, you can [ask on GitHub](https://github.com/getsentry/sentry-javascript/issues/new/choose). Customers on a paid plan may also contact support.

## Pages in this section

- [Supported Browsers](https://docs.sentry.io/platforms/javascript/guides/cloudflare/troubleshooting/supported-browsers.md)