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 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