Disable Sentry in development environment (or any other env) using Next.js/Node.js

disable-sentry.md

Disable Sentry in development environment (or any other)

Look for Sentry config file/s (sentry.client.js & sentry.config.js)

Either file should contain an object like this

Sentry.init({
  dsn: DSN_YOU_ACQUIRED_FROM_SENTRY
})

To disable Sentry in any env you can make use of enabled flag in Sentry config and process.env.NODE_ENV Node.js environment variable. This variable is built into Node.js and is set to 'development' or 'production' depending on your app environment.

To disable in development, do the following;

Sentry.init({
  dsn: DSN_YOU_ACQUIRED_FROM_SENTRY,
  enabled: process.env.NODE_ENV === 'production'
})

Now Sentry will only be active in Production environment.

Read more on Sentry configuration in the official Docs.

I'm using Sentry in Next.js. How to do this in it? There's no enabled option in either of the two JSON blocks (as per Intellisense suggestions).

const { withSentryConfig } = require('@sentry/nextjs')

module.exports = withSentryConfig(
  module.exports,
  {
    // For all available options, see:
    // https://github.com/getsentry/sentry-webpack-plugin#options

    // Suppresses source map uploading logs during build
    silent: true,

    org: 'my-org',
    project: 'my-project',
  },
  {
    // For all available options, see:
    // https://docs.sentry.io/platforms/javascript/guides/nextjs/manual-setup/

    // Upload a larger set of source maps for prettier stack traces (increases build time)
    widenClientFileUpload: true,

    // Transpiles SDK to be compatible with IE11 (increases bundle size)
    transpileClientSDK: true,

    // Routes browser requests to Sentry through a Next.js rewrite to circumvent ad-blockers (increases server load)
    tunnelRoute: '/monitoring',

    // Hides source maps from generated client bundles
    hideSourceMaps: true,

    // Automatically tree-shake Sentry logger statements to reduce bundle size
    disableLogger: true,
  },
)

Never mind, it looks like I have to search for Sentry.init in the project to find it, then set the option in all the instances there.

@ADTC
I'm glad it worked out for you!

Thanks 🙌

I wanted to skip compiling /instrumentation.ts (which is what calls Sentry.init) to reduce the next dev startup time, so I disable it by turning it off from the next config:

const nextConfig = {
   ...
}

let config = withBundleAnalyzer(nextConfig)

config = withSentryConfig(config, {
    ...
}

module.exports = {
  ...config,
  experimental: {
    instrumentationHook: process.env.NODE_ENV === 'production',
  },
}

I had to lay it out like this as I had custom rewrites and webpack, which withSentryConfig will modify so it must be done in this order to preserve all the settings.

On Sentry v8+ you need to do something like this on your instrument file:

process.env.NODE_ENV === 'production' &&
  Sentry.init({ ... })

and call it conditionally per their docs

thanks @Shahaed!

I wanted to skip compiling /instrumentation.ts (which is what calls Sentry.init) to reduce the next dev startup time, so I disable it by turning it off from the next config:

const nextConfig = {
   ...
}

let config = withBundleAnalyzer(nextConfig)

config = withSentryConfig(config, {
    ...
}

module.exports = {
  ...config,
  experimental: {
    instrumentationHook: process.env.NODE_ENV === 'production',
  },
}

I had to lay it out like this as I had custom rewrites and webpack, which withSentryConfig will modify so it must be done in this order to preserve all the settings.

@mozeryansky I find your solution more elegant than conditionnally calling Sentry.init 👍 thanks !

Noteworthy : running instrumentation (for nothing) took 3s on my runs, both on CI and locally. I'm on the hunt of such wastes !

@seedy Exactly! I wasn't just interested in turning it off, but in reducing my local build time. Took a while to figure this out, especially since Sentry overwrites the config, but the time spent on this definitely helps my development iteration time.

I wanted to skip compiling /instrumentation.ts (which is what calls Sentry.init) to reduce the next dev startup time, so I disable it by turning it off from the next config:

const nextConfig = {
   ...
}

let config = withBundleAnalyzer(nextConfig)

config = withSentryConfig(config, {
    ...
}

module.exports = {
  ...config,
  experimental: {
    instrumentationHook: process.env.NODE_ENV === 'production',
  },
}

I had to lay it out like this as I had custom rewrites and webpack, which withSentryConfig will modify so it must be done in this order to preserve all the settings.

@mozeryansky I find your solution more elegant than conditionnally calling Sentry.init 👍 thanks !

Noteworthy : running instrumentation (for nothing) took 3s on my runs, both on CI and locally. I'm on the hunt of such wastes !

This approach doesn't work

This approach doesn't work

I use it everyday just fine. Instead of only saying it doesn't work, can you share what you believe isn't working for you? If it's an issue with Sentry then you should contact their support.

In Next.js 15, the instrumentationHook experimental flag was removed as the feature was stabilized.

To disable instrumentation in development environments, you can add an environment check:

export async function register() {
if (process.env.NODE_ENV !== 'production') {
return;
}
if (process.env.NEXT_RUNTIME === 'nodejs') {
await import('./instrumentation-node')
}
if (process.env.NEXT_RUNTIME === 'edge') {
await import('./instrumentation-edge')
}
}

While this approach works functionally, there's a caveat: Next.js still bundles the instrumentation code even though it's not being used in development.

I've submitted a feature request here to propose a solution that would allow completely disabling instrumentation in development environments.

@JamesRobertWiseman this is what I do now in Next.js 15:

const nextConfig: NextConfig = {
  ...
}

if (process.env.SENTRY === 'true' || process.env.NODE_ENV === 'production') {
  const { withSentryConfig } = require('@sentry/nextjs')

  config = withSentryConfig(config, {
    ...
  })

  module.exports = {
    ...config,
    serverExternalPackages: ['@sentry/profiling-node'],
    async rewrites() {
      return await nextConfig.rewrites()
    },
  }
} else {
  module.exports = config
}

My instrumentation.ts is:

import { Sentry } from '@/lib/sentry'

export async function register() {
  if (process.env.NEXT_RUNTIME === 'nodejs') {
    await import('../sentry.server.config')
  }

  if (process.env.NEXT_RUNTIME === 'edge') {
    await import('../sentry.edge.config')
  }
}

export const onRequestError = Sentry.captureRequestError

and my @/lib/sentry ensures no import: (I use SENTRY=true when testing locally)

let Sentry = {
  setUser: any => {},
  captureException: e => '',
  captureRequestError: any => {},
  getFeedback: () =>
    undefined as
      | undefined
      | {
          attachTo: (any) => undefined
        },
  addEventProcessor: any => any,
}

if (process.env.SENTRY === 'true' || process.env.NODE_ENV === 'production') {
  Sentry = require('@sentry/nextjs')
}

export { Sentry }

I had a lot of trouble using --turbo but it's still fairly in beta and I find that not using it is still much faster in my own testing.

In Next.js 15, the instrumentationHook experimental flag was removed as the feature was stabilized.

To disable instrumentation in development environments, you can add an environment check:

export async function register() {
if (process.env.NODE_ENV !== 'production') {
return;
}
if (process.env.NEXT_RUNTIME === 'nodejs') {
await import('./instrumentation-node')
}
if (process.env.NEXT_RUNTIME === 'edge') {
await import('./instrumentation-edge')
}
}

While this approach works functionally, there's a caveat: Next.js still bundles the instrumentation code even though it's not being used in development.

I've submitted a feature request here to propose a solution that would allow completely disabling instrumentation in development environments.

super simple and worked for me, thank you

thanks @Shahaed that worked.

I wanted to skip compiling /instrumentation.ts (which is what calls Sentry.init) to reduce the next dev startup time, so I disable it by turning it off from the next config:

const nextConfig = {
   ...
}

let config = withBundleAnalyzer(nextConfig)

config = withSentryConfig(config, {
    ...
}

module.exports = {
  ...config,
  experimental: {
    instrumentationHook: process.env.NODE_ENV === 'production',
  },
}

I had to lay it out like this as I had custom rewrites and webpack, which withSentryConfig will modify so it must be done in this order to preserve all the settings.

This worked. Thank you!

@JamesRobertWiseman this is what I do now in Next.js 15:

const nextConfig: NextConfig = {
  ...
}

if (process.env.SENTRY === 'true' || process.env.NODE_ENV === 'production') {
  const { withSentryConfig } = require('@sentry/nextjs')

  config = withSentryConfig(config, {
    ...
  })

  module.exports = {
    ...config,
    serverExternalPackages: ['@sentry/profiling-node'],
    async rewrites() {
      return await nextConfig.rewrites()
    },
  }
} else {
  module.exports = config
}

My instrumentation.ts is:

import { Sentry } from '@/lib/sentry'

export async function register() {
  if (process.env.NEXT_RUNTIME === 'nodejs') {
    await import('../sentry.server.config')
  }

  if (process.env.NEXT_RUNTIME === 'edge') {
    await import('../sentry.edge.config')
  }
}

export const onRequestError = Sentry.captureRequestError

and my @/lib/sentry ensures no import: (I use SENTRY=true when testing locally)

let Sentry = {
  setUser: any => {},
  captureException: e => '',
  captureRequestError: any => {},
  getFeedback: () =>
    undefined as
      | undefined
      | {
          attachTo: (any) => undefined
        },
  addEventProcessor: any => any,
}

if (process.env.SENTRY === 'true' || process.env.NODE_ENV === 'production') {
  Sentry = require('@sentry/nextjs')
}

export { Sentry }

I had a lot of trouble using --turbo but it's still fairly in beta and I find that not using it is still much faster in my own testing.

Hey @mozeryansky, did you get any improvement in local development after doing this? I also want to disable sentry completely on local dev & build.

I am going to try this now! Thanks.

@dalalRohit It speeds up local builds when running npm run dev significantly. ymmv

Thanks for this @mozeryansky !

const nextConfig: NextConfig = {
  ...
}

if (process.env.SENTRY === 'true' || process.env.NODE_ENV === 'production') {
  const { withSentryConfig } = require('@sentry/nextjs')

  config = withSentryConfig(config, {
    ...
  })

  module.exports = {
    ...config,
    serverExternalPackages: ['@sentry/profiling-node'],
    async rewrites() {
      return await nextConfig.rewrites()
    },
  }
} else {
  module.exports = config
}

Btw, with the linter i was having an issue that A require() style import is forbidden. As the require() is necessary because Next.js config files are executed in CommonJS context, I added this comment to disable the check:

  // eslint-disable-next-line @typescript-eslint/no-require-imports
  const { withSentryConfig } = require('@sentry/nextjs');