Filtering "Failed to Fetch" Errors with Sentry's `beforeSend` Configuration

Aron Schüler Published Jun 20, 2024

Intro

Error monitoring is crucial for maintaining health and performance of our applications. We use Sentry to monitor crashes in real-time and I especially value it for the new Session replay feature. However, not all errors are actionable. For instance, we have a lot of noise coming from AdBlocker that cause “Failed to fetch” errors. The useres’ adblockers block requests to analytics services like analytics.google.com and googletagmanager.com, but Sentry captures these exceptions none the less and they end up in our dashboard. This easily leads to a lot of noise when you have various scripts being blocked. Worst case, it might bury an important exception that you just oversaw along all these false-positives! In this post, I describe how I used Sentry’s beforeSend configuration to filter out these non-actionable errors.

Step-by-Step Guide

1. Step 1: Setting Up Sentry in Your Project

   • First, ensure you have Sentry set up in your project. This should be done already, but if you haven’t done this yet, install the Sentry SDK for JavaScript using npm or yarn:

     npm install @sentry/browser
     # or
     yarn add @sentry/browser

   • Initialize Sentry in your project, typically in your main JavaScript or TypeScript file:

     import * as Sentry from "@sentry/browser";
      
     Sentry.init({
       // ... other configuration options depending on your framework and environment
       dsn: "YOUR_SENTRY_DSN",
     });

2. Step 2: Implementing the beforeSend Configuration

   • The beforeSend hook allows you to modify or drop events before they are sent to Sentry. We’ll use this hook to filter out errors related to adblockers.

   • Add the following code to your Sentry initialization:

     import * as Sentry from "@sentry/browser";
      
     const handleSentryBeforeSend = (event: Sentry.Event) => {
       const ignoredUrls = ["analytics.google.com", "googletagmanager.com"];
       if (
         ignoredUrls.some((url) =>
           event.breadcrumbs?.some((breadcrumb) =>
             breadcrumb.data?.url.includes(url),
           ),
         )
       ) {
         return null;
       }
      
       return event;
     };
      
     Sentry.init({
       dsn: "YOUR_SENTRY_DSN",
       beforeSend: handleSentryBeforeSend,
     });

     This is based on the assumption that the URLs of the blocked requests are captured in the breadcrumbs of the Sentry event. You might need to adjust this logic based on how your application logs these errors. I took a look at the Sentry event object in an event in Sentry and found that the URL is stored in the breadcrumb.data.url property.

3. Step 3: Testing Your Configuration

   • To ensure your configuration works as expected, trigger some fetch errors in your application. You can use browser developer tools to manually disable network requests to the ignored URLs or just visit your website with an adblocker enabled.
   • Check your Sentry dashboard to verify that errors related to analytics.google.com and googletagmanager.com are no longer being reported.

4. Step 4: Refining the Filter Logic (Optional)

   • Depending on your needs, you might want to refine the filter logic further. For example, you might want to drop events in other scenarios as well or log the ignored errors for future reference.

   • Modify the handleSentryBeforeSend function to include additional logic as needed:

     const handleSentryBeforeSend = (event: Sentry.Event) => {
       const ignoredUrls = ["analytics.google.com", "googletagmanager.com"];
       const isIgnoredError = ignoredUrls.some((url) =>
         event.breadcrumbs?.some((breadcrumb) =>
           breadcrumb.data?.url.includes(url),
         ),
       );
      
       if (isIgnoredError) {
         // Optionally log ignored errors
         console.log("Ignored error:", event);
         return null;
       }
      
       // Handle event further
       if (event.message === "Some other error message") {
         // Drop the event
         return null;
       }
      
       return event;
     };

Conclusion

By configuring Sentry’s beforeSend hook, you can effectively filter out non-actionable “Failed to fetch” errors caused by adblockers. This helps keep your Sentry dashboard clean and focused on more critical issues that require your attention. We managed to reduce noise by filtering out these errors and can now focus on actionable exceptions that need immediate attention. Expand these filters as necessary and hopefully you will end up with only valuable information in your Sentry dashboard.