21

We're using Sentry in our React project by adding the following to our main index.js and App.js files:

index.js

// Import Stuff
import * as Sentry from '@sentry/react';
import { Integrations } from '@sentry/tracing';
... import other important react stuff...

// https://sentry.io/onboarding/cbb-analytics/get-started/ (not my real dsn)
Sentry.init({
    dsn: 'https://asdkfa930209jcdzkljaasdfasdf@o123456.ingest.sentry.io/3293942',
    integrations: [
        new Integrations.BrowserTracing()
    ],
    tracesSampleRate: 1.0
});

ReactDOM.render(
    <BrowserRouter>
        <App />
    </BrowserRouter>,
    document.getElementById('root'));

App.js

import * as Sentry from '@sentry/react';
... other imports for app.js ...

// And Create The App
function App() {
    // check logged in...
    // check global state...
    // fetch some global data...

    return (
        <GlobalContext.Provider value={globalStateObj}>
            <AppNavbar />
            <LoginModal />
            <Sentry.ErrorBoundary fallback={ErrorBoundaryFallback}>
                <Switch>
                    <Route exact path='/' render={(props) => <HomePage {...props} />}
                    <Route exact path='/about-us' component={AboutUs} />
                    <Route exact path='/reports' component={Reports} />
                    <Route component={NoMatch} />
                </Switch>
            </Sentry.ErrorBoundary>

            <AppFooter />
        </GlobalContext.Provider>
    );
}

export default App;

We could certainly be more granular with our Error Boundaries, but as it stands, wrapping the whole switch, which contains 99% of the code in our app, is getting the job done for us. Whenever a user runs into any issue on the website, we're getting that as an issue in Sentry.

However, we would prefer it if Issues weren't created in Sentry if the error comes from dev / localhost... We break stuff / get errors all the time in dev when writing new code, and sending these as issues to Sentry just clutters Sentry and makes it a bit harder to keep track of those important errors that happen in production.

Can we use our process.env.NODE_ENV to determine dev vs prod, and use this somewhere in index.js or in App.js to prevent issues from being sent for localhost? Or perhaps sentry has a way to explicitly ignore issues from an ip, like localhost:3000?

Canovice
  • 9,012
  • 22
  • 93
  • 211

6 Answers6

26

Set enabled in the Sentry config to false when not in production.

Sentry.init({
    dsn: 'your-dsn',
    integrations: [
        new Integrations.BrowserTracing()
    ],
    tracesSampleRate: 1.0, // Should not use 1.0 in production
    enabled: process.env.NODE_ENV !== 'development',
});

Side note: Sentry discourages setting tracesSampleRate to 1.0 in production

Isaac Overacker
  • 1,385
  • 10
  • 22
11

The easiest way I could get it working was to set the beforeSend method in Sentry.init to return null if the location is localhost.

Sentry.init({
  dsn:
    'your dsn here',
  integrations: [new Integrations.BrowserTracing()],
  tracesSampleRate: 1.0

  beforeSend: (event) => {
    if (window.location.hostname === 'localhost') {
      return null;
    }
    return event;
  },
});
Peet
  • 697
  • 9
  • 9
  • I like this option since this will also allow us to print (stdout/stderr) messages in development vs production – user1928896 Jun 04 '23 at 23:03
  • 1
    Perhaps Try looking for `Inbound Filter` inside Project Settings in Sentry. It does the same and doesn't count against quotas as well. – KeshavDulal Jul 20 '23 at 10:25
9

2023-July Answer

Try looking for Inbound Filter inside Project Settings in Sentry.

It has an option to filter-out localhost.

This doesn't count against quotas as well.

Inbound Data Filter Option in Sentry

KeshavDulal
  • 3,060
  • 29
  • 30
  • Is this based on the IP address or the URL? Because the errors show the real IP address, while only the URL field has `127.0.0.1` embedded in it. – ADTC Aug 28 '23 at 01:42
  • Looks like it is based on the URL. It has already begun filtering out the events from our developers' local environments. Thanks! :) – ADTC Aug 28 '23 at 02:53
1

Write a function to know you're on dev using location or with some dev-env or with process.env or .env file... nevermind

function onDev() {
  return window.location.href.startsWith('http://localhost');
}

then create a Wrapper like

function SentryNoDev({ErrorBoundaryFallback, children}) {
   return onDev()
   ? children
   : <Sentry.ErrorBoundary fallback={ErrorBoundaryFallback}>{children}</Sentry.ErrorBoundary>
   ;
}
farvilain
  • 2,552
  • 2
  • 13
  • 24
  • I guess it really can be this simple. I'll give this a shot, although I don't see why it wouldn't work. Thanks – Canovice Nov 04 '20 at 21:21
  • So this doesn't work. Interestingly, I removed the `Sentry.ErrorBoundary` all-together, and yet I am still getting issues sent to Sentry. So the `Sentry.ErrorBoundary` only handles error handling, whereas the `Sentry.init` is what I really need to handle... – Canovice Nov 05 '20 at 00:58
  • per https://github.com/getsentry/sentry-java/issues/574, it looks like setting the `DSN` to null is the way to go... – Canovice Nov 05 '20 at 01:00
  • Unfortunately with this implementation, you don't see the error boundary when getting errors when running locally. I've posted a solution that preserves the error boundary. – Peet Apr 27 '21 at 10:33
1

In Create-React-App

// index.js
if (process.env.NODE_ENV === 'production') {
  Sentry.init({...});
}
weiliang
  • 663
  • 8
  • 13
0
  • I don't recommend you put your dsn in the code i would suggest you set it to an env variable for example REACT_APP_SENTRY_DSN

  • wherever you supply your env variable you can put your dsn there

  • if you supply the env variables through netlify for example the REACT_APP_ENV for staging be 'staging' for production 'production' then

let shouldSendToSentry = 
  ['staging','production'].includes(process.env.REACT_APP_ENV)

2 ways from here

  • wrap your sentry config in an if condition for example:
if(shouldSendToSentry ){
  sentry.init({
    dsn: process.env.REACT_APP_SENTRY_DSN
  })
}
  • the other way is by
beforeSend: (event) => {
    if (!shouldSendToSentry) {
      return null;
    }
return event;

which in this case it will ignore all issues coming from any other environments

resources: