When Sentry Burned Through Its Event Quota in Days — Trimming Noise Before It Ships

tracesSampleRate and sampleRate are not the same

Before the code, separate two settings that are easy to confuse. Mix them up and you think you have throttled errors while traces keep draining the quota.

Half of my first quota meltdown came from shipping with tracesSampleRate: 1.0 left over from development. Traces, not errors, were eating the budget. Rather than lower the error sampleRate, drop only the noise surgically in beforeSend. That division of labor is the starting point.

import * as Sentry from "@sentry/react-native";
 
Sentry.init({
  dsn: "https://YOUR_KEY@o0.ingest.sentry.io/YOUR_PROJECT",
  environment: __DEV__ ? "development" : "production",
  release: "app@1.4.0",
 
  // Send all errors as a rule; drop noise individually in beforeSend
  sampleRate: 1.0,
 
  // Throttle performance traces hard in production (a common quota drain)
  tracesSampleRate: __DEV__ ? 1.0 : 0.05,
 
  // Never even send known harmless messages
  ignoreErrors: [
    "AbortError",
    "Network request failed",
    "TypeError: Network request failed",
    /Non-Error promise rejection captured/,
  ],
});

ignoreErrors filters by message via strings or regex — the simplest entry point. But on its own it also drops network errors you may actually want. That is why we move on to beforeSend, where you can decide conditionally.

Drop it client-side in beforeSend

beforeSend is a hook that runs right before an event is sent to Sentry. Return null and the event is never sent. The advantage is real: you discard it before it consumes any quota.

Write the conditions for noise you are willing to swallow in meaningful units.

Sentry.init({
  // ...settings above...
  beforeSend(event, hint) {
    const error = hint?.originalException;
    const message =
      (typeof error === "string" ? error : error?.message) || "";
 
    // 1. A fetch aborted because the user left the screen is harmless
    if (error?.name === "AbortError") {
      return null;
    }
 
    // 2. Offline-driven network failures are frequent and self-explanatory,
    //    but keep non-offline network failures, so scope the condition
    if (
      message.includes("Network request failed") &&
      event.contexts?.app?.in_foreground === false
    ) {
      return null;
    }
 
    // 3. Internal warnings from a specific third-party SDK you cannot fix
    const frames =
      event.exception?.values?.[0]?.stacktrace?.frames || [];
    const fromNoisySdk = frames.some((f) =>
      (f.filename || "").includes("some-analytics-sdk")
    );
    if (fromNoisySdk) {
      return null;
    }
 
    return event;
  },
});

The point is to treat beforeSend not as "the place to reduce volume uniformly" but as "the place to write down why something is harmless." Drop it because it is an AbortError; drop it because it is a network failure while not in the foreground. When the reason is spelled out, the decision stays safe to reread later.

Loading unhandled exceptions from the React component tree into Sentry pairs well with the Error Boundary and unhandled promise design, so capture and suppression work together.

Group persistent noise with fingerprint

Some events are not worth deleting outright, yet arrive in bulk. For those, collapse them into one issue rather than dropping them. Sentry splits by stack trace differences, but a fingerprint forces grouping.

beforeSend(event, hint) {
  const error = hint?.originalException;
  const message = error?.message || "";
 
  // 5xx tends to fragment into many issues via query-string or request-id
  // differences. Collapse to one per endpoint
  if (message.startsWith("HTTP 5")) {
    const endpoint = (error?.url || "unknown").split("?")[0];
    event.fingerprint = ["http-5xx", endpoint];
  }
 
  return event;
}

Grouping itself does not directly cut quota usage. But when 100 fragmented issues collapse into one, "what is actually high-volume" becomes obvious at a glance. That makes the next sampling or beforeSend target clear, and the decision to stop wasteful sends comes faster.

Crashlytics has no cap, but that is not license to send everything

One cost note. Firebase Crashlytics has no event limit, so raw volume is not a concern. That part is relaxing.

But if you keep "unlimited means send it all," the dashboard fills with noise instead. Record non-fatals unconditionally with recordError() and the fatal crashes sink into a sea of counts.

import crashlytics from "@react-native-firebase/crashlytics";
 
// Tag non-fatals with a severity attribute so you can filter later
function recordNonFatal(error, severity = "warning") {
  crashlytics().setAttribute("severity", severity);
  crashlytics().recordError(error);
}

Even without a cap, the stance is the same: judge severity before you record. Limit or no limit, not sending noise is what protects your own visibility. This classification thinking is continuous with running actionable crash reports and staged distribution.

Always let critical errors through after sampling

The scariest part of trimming noise is dropping an important error along with it. To prevent that, I put an "always send" guard at the very top of beforeSend.

const ALWAYS_SEND = new Set([
  "PaymentError",       // billing can never be missed
  "AuthTokenMissing",   // auth failure stops the user completely
  "DataCorruption",     // corrupted saved data breaks trust
]);
 
beforeSend(event, hint) {
  const error = hint?.originalException;
 
  // allowlisted names pass unconditionally, before any suppression rule
  if (error?.name && ALWAYS_SEND.has(error.name)) {
    return event;
  }
 
  // suppression rules for AbortError etc. go below
  // ...
  return event;
}

Design suppression as "when in doubt, keep it." Only drop what you can state, with reasons, is harmless. Anything you hesitate over, send. Prioritize not missing errors over protecting the quota. As long as that ordering holds, sampling stays a safe tool.

The numbers after rolling it out (field notes)

I ran this on one app for about two weeks. As an indie developer, I make every change myself and observe it myself.

Monthly sends were on pace for about 18,000 before the changes. Breaking it down in Discover, AbortError was roughly 61%, and traces from tracesSampleRate: 1.0 were the other pillar of pressure.

After lowering tracesSampleRate to 0.05 and dropping AbortError plus non-foreground network failures in beforeSend, the pace fell to about 3,200 events per month — a little over 60% of the 5,000 free tier.

What mattered came next: I deliberately triggered a payment error in staging and confirmed it passed the ALWAYS_SEND allowlist and reached Sentry. Noise down, fatal errors still through — you can only claim you protected the quota once both are verified. Not relaxing just because the number dropped is, I think, the biggest trap in this kind of work.

Turn it into a weekly triage

Finally, the minimal routine so this does not stay a one-off. Keep it coarse enough to run in five minutes.

The goal of monitoring is not to record a lot; it is to have the error you need still there when you need it. Trimming noise before it ships is a quiet but effective way to keep that state inside a free tier.

Open your own project's Discover and find the single highest-volume issue over the last 7 days. If it is harmless, one line in beforeSend will change your consumption immediately. I hope this helps with your own setup. Thank you for reading.