#Is it possible to disable Sentry data gathering and issue creation for specific environment variable

9 messages · Page 1 of 1 (latest)

wraith geyser
#

Is it possible to disable Sentry data gathering and issue creation for specific environment variables (e.g. development because when testing locally you get all kind of issues every other second) and for specific Git branches (e.g. dependabot/**)

hybrid deltaBOT
#

Hi @wraith geyser. I'm happy to dig into this for you! I'll check my internal sources for answers to your question! :wave:

#

Yes. Based on the docs and issues, there are two main patterns:

1. Disable Sentry per environment

Across SDKs you can either:

a) Not initialize Sentry in that environment

For example, in Ruby on Rails you can wrap initialization:

unless Rails.env.development?
  Sentry.init do |config|
    # ...
  end
end

This prevents any data from being gathered or sent in development at all.[GH ruby #2454]

Similarly, the general recommendation is “don’t init the SDK” in environments where you don’t want events.[GH dart #1620]

b) Use SDK options like enabled_environments / enabled

For Ruby SDKs (Rails, Rack, Sidekiq, Resque, etc.) you can restrict to specific environments:

Sentry.init do |config|
  config.enabled_environments = %w[production staging]
end

Then development (or any env not listed) won’t send events.[Ruby options][Rails options]

For JavaScript, there is an enabled option on Sentry.init:

Sentry.init({
  dsn: 'your-dsn',
  enabled: process.env.NODE_ENV !== 'development',
});

This disables Sentry entirely when NODE_ENV === 'development'.[JS discussion]

c) Filter events via hooks (e.g. beforeSend)

If you still want Sentry initialized but want to drop all events for a given environment, you can use beforeSend:

# 
Sentry.init({
  dsn: 'your-dsn',
  beforeSend(event) {
    if (process.env.REACT_APP_ENVIRONMENT === 'development') {
      return null; // drop event
    }
    return event;
  },
});

Returning null prevents the event from being sent (no issue created).[Zendesk article]

A similar idea exists in other SDKs (e.g. beforeSend, before_emit_metrics, etc.).[GH dart #1620][GH ruby #68064]

2. Disable for specific Git branches (e.g. dependabot/**)

The provided knowledge sources do not explicitly describe filtering by Git branch name. They only cover:

  • Environment-based enabling/disabling (enabled_environments, enabled, not initializing).
  • Event filtering hooks like beforeSend / before_emit_metrics.
  • Project-level inbound filters (but not specifically by branch).[Inbound filters issue]

So, from these sources alone, there is no documented, built‑in “branch filter” setting. You would need to derive such behavior yourself (for example, by using a hook like beforeSend and some branch information you attach to the event), but the exact implementation is not described in the materials you provided, so I can’t give a concrete, documented code example for branch-based filtering.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@wraith geyser Our robots are still learning and improving, please let us know if this response was correct by reacting below.

wraith geyser
#

@hybrid delta its a nuxt/nitro/vue/typescript context.

beforeSend already sounds great, how would Environment-based enabling/disabling look like in this context?

hybrid deltaBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

In Nuxt/Nitro/Vue/TypeScript you have two main levers, both shown in the Nuxt-specific Sentry examples from the knowledge sources:

1. Control initialization via enabled

You can pass enabled to Sentry.init and derive it from environment variables or runtime config.

Client-side (sentry.client.config.ts) using runtime config (pattern from multiple Nuxt issues):

import * as Sentry from '@sentry/nuxt'

const { public: { sentry } } = useRuntimeConfig()

Sentry.init({
  dsn: sentry.dsn,
  environment: sentry.environment,
  enabled: sentry.environment !== 'development',
  integrations: [
    Sentry.browserTracingIntegration({ router: useRouter() }),
    Sentry.replayIntegration({
      maskAllInputs: false,
      maskAllText: false,
    }),
  ],
  tracesSampleRate: 0.2,
  replaysSessionSampleRate: 0,
  replaysOnErrorSampleRate: 1.0,
})

This follows the same pattern as the official Nuxt examples that use enabled with env vars. [Nuxt sourcemaps issue; Nuxt runtime config request]

Server-side (sentry.server.config.ts) using env vars:

import * as Sentry from '@sentry/nuxt'

Sentry.init({
  dsn: process.env.NUXT_PUBLIC_SENTRY_DSN,
  environment: process.env.APP_ENV,
  enabled: process.env.APP_ENV !== 'development',
  tracesSampleRate: 0.0,
})

This mirrors the server config examples that already use process.env for dsn and environment. [Nuxt server errors; Nitro utils issue]

#

Note: The Nuxt docs also mention the core enabled option for the JS SDK. [Nuxt enabled option]

2. Disable the Nuxt Sentry module entirely per environment

One Nuxt issue shows conditionally adding the module so it’s not even loaded in tests:

// nuxt.config.ts
export default defineNuxtConfig({
  modules: [
    process.env.NODE_ENV !== 'test' && '@sentry/nuxt/module',
  ],
})

[Nuxt module enabled request]

You can adapt this to skip Sentry in development as well if you want zero overhead there.

3. Combine with beforeSend for fine-grained dropping

The general Sentry guidance is: you can still initialize Sentry everywhere but drop events in certain environments using beforeSend. [Disable per env]

In Nuxt client config that would look like:

import * as Sentry from '@sentry/nuxt'

const config = useRuntimeConfig()

Sentry.init({
  dsn: config.public.sentry.dsn,
  environment: config.public.sentry.environment,
  beforeSend(event) {
    if (config.public.sentry.environment === 'development') {
      return null // drop all events in dev
    }
    return event
  },
})

This way you can keep Sentry initialized (for local debugging, Replay, etc.) but prevent any issues from being created in specific environments.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: