One error is flooding your Sentry inbox: how to stop an error loop

A typical case: a deploy goes out, a component sets state in useEffect, and the same TypeError: Cannot read properties of undefined fires on every render in every open tab. The issue list shows one row at 40,000 events and climbing. The quota email follows, and the next real error sits underneath the loop. The way out is the same each time. Prove it is one loop, stop it in code, and filter only that event while the fix rolls out.

How do you know one error is flooding Sentry and not an outage?

One looping error shows up in Sentry as one issue whose event count grows by thousands an hour while the number of issues stays flat. Sort the Issues list by events, or follow Sentry's event-stream guide: open the Errors page, add the issue, title, project and count() columns, and sort by count. If one row holds most of the last hour's volume, you have a loop. If ten unrelated issues rose in the same minute, a dependency is down, and filtering would hide the outage.

Two more checks settle it. Open two events of the suspect issue and compare the stack trace and the release tag: a loop repeats the same frames from the same release. Then open Stats > Usage Stats, which shows accepted, dropped and filtered events per project for up to 90 days, and find the hour the volume started. That hour usually matches a deploy or a scheduled job.

What causes one error to repeat thousands of times?

An error loop is code that retries or re-renders without a stop condition, so the same exception fires at machine speed. A failing request retried every 50 ms throws 20 errors a second from each open tab. A React component that throws during a render triggered by its own state update repeats on every pass. The loop is rarely the bug that matters most, but it decides how much room your inbox and your quota have left.

• Retry without backoff: a fetch call or queue consumer retries on error with no maximum attempt count.
• Render loop: a state update in useEffect or a subscription re-triggers a render that throws again.
• Polling a broken endpoint: a dashboard tab polls on a timer and every response fails.
• Logs captured as errors: SDK integrations turn logger.error calls into events. One DEV post traced a jump from about 5 issues a day to more than 4,000 to integrations the Python SDK 2.x enables on its own, such as LoguruIntegration.
• Code you don't own: a browser extension or an injected third-party script throws inside your page.

How do you stop an error loop at the source?

Fixing the code path is the only option that stops the flood for your users as well as for Sentry, because the loop also spends their CPU and your API rate limits. Give retries a maximum attempt count and a growing delay; 3 attempts starting at 1 second turns an endless stream into one error per failed request. Guard the state update that re-triggers the render. Ship the change with a new release value so old and new events are easy to tell apart. Filters come second, as a way to hide the symptom while the fix rolls out.

async function fetchWithRetry(url: string, attempts = 3): Promise<Response> {
  for (let i = 0; i < attempts; i++) {
    const res = await fetch(url);
    if (res.ok) return res;
    await new Promise((resolve) => setTimeout(resolve, 1000 * 2 ** i)); // 1 s, 2 s, 4 s
  }
  // One error per failed request instead of one per retry, forever.
  throw new Error("GET " + url + " failed after " + attempts + " attempts");
}

How do you filter one error in Sentry with beforeSend?

Sentry's beforeSend hook receives every error event before the SDK sends it, and returning null drops the event, so it never reaches Sentry or your quota. Match on the original exception through hint.originalException and keep the rule as narrow as the loop, for example one message from release web@1.42.0. The JavaScript filtering docs describe the hook as the last chance to drop or edit data (checked 6 Nov 2026). The option works the same in @sentry/nextjs as in @sentry/browser.

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  beforeSend(event, hint) {
    const err = hint.originalException;
    // Temporary, remove after 2026-11-20: checkout retry loop in web@1.42.0.
    if (
      event.release === "web@1.42.0" &&
      err instanceof Error &&
      err.message.startsWith("Checkout request failed")
    ) {
      return null;
    }
    return event;
  },
});

Write the removal date into the comment, and send a second, known test error from staging to check that the rule drops only the loop. In Python's sentry-sdk the hook is before_send, and returning None skips the event (Python options, checked 6 Nov 2026).

Should you use ignoreErrors, denyUrls or allowUrls instead?

Sentry's JavaScript SDK offers ignoreErrors, denyUrls and allowUrls as declarative filters for loops that don't need code to identify. ignoreErrors matches the error message, and a plain string matches partially, so "Checkout" would drop every message that contains the word. Use a regular expression such as /^Checkout request failed$/ for an exact match. denyUrls and allowUrls match the script URLs in the stack frames, not the page URL, which makes them the right tool when a browser extension or a third-party widget throws inside your page.

Python behaves differently: ignore_errors takes exception class names such as ConnectionResetError and also filters their subclasses. For browser code you don't own, thirdPartyErrorFilterIntegration (browser SDKs from 8.10.0) can drop or tag errors whose frames come from third-party scripts. That integration needs Sentry's bundler plugin and does not work with the Loader Script or CDN bundles.

Does lowering sampleRate stop Sentry error spam?

Lowering sampleRate cuts every error type by the same fraction, so it shrinks the flood and your rare bugs together. The option defaults to 1.0. At 0.1, a loop of 72,000 events an hour still sends about 7,200, while a bug that fires twice a day reaches Sentry about once every five days. Sentry's event-stream guide also notes that the rate is fixed in code, so each change needs a redeploy. Reach for it to cap a budget you can't control any other way, and use a targeted filter for one loop.

If the volume is spans rather than errors, tracesSampleRate is the setting to change. Turning off Sentry tracing while keeping errors walks through that change for each SDK.

Which Sentry settings stop a flood without a redeploy?

Sentry's server-side settings act on events after they arrive, so they take effect without a deploy. Per project, Settings > Inbound Filters has built-in toggles for browser-extension errors, localhost, known legacy browsers and web crawlers, plus IP address blocking. Events these filters drop do not count toward quota, according to Sentry's quota docs (checked 6 Nov 2026). Filters by error message or by release, which would catch a loop directly, are listed for Business and Enterprise plans only.

• Spike protection computes a threshold per project from the last 168 hours of usage and drops events above it while the spike lasts, so the excess is not charged. A Manager, Billing or Owner member turns it on in Settings > Spike Protection. Notifications are a separate action you add (spike protection docs).
• Per-key rate limits cap one DSN key per minute, hour or day, and events over the cap get a 429. The event-stream guide lists them for Business and Enterprise.
• Delete and discard removes an issue and drops its future events, also on Business and Enterprise. Ignoring or archiving an issue does less: Sentry still counts every repeated event of an ignored issue toward quota.

Spike protection has one property to know before a flood. The threshold is set per project, not per issue, and the docs don't describe any exemption for other issues while it is active. A new error that starts during the loop therefore competes for the same allowance as the loop itself.

How fast does an error loop use up the Sentry quota?

An error loop can use Sentry's included errors in minutes. The Developer plan includes 5,000 errors a month and Team includes 50,000 (sentry.io/pricing, checked 6 Nov 2026). The table divides those allowances by three loop rates and prices one hour of each on Team pay-as-you-go. Past the allowance and any budget, Sentry refuses new events until the next usage period, and refused events cannot be recovered; the guide to Sentry quota exceeded covers what that hides.

To model your own rates and plan, use the Sentry pricing calculator. It uses the same public per-event rates and shows when the included errors run out.

Is there an error tracker that isolates floods per fingerprint?

Epure error tracking limits stored payloads per fingerprint instead of per project, so a loop cannot use up the room a new error needs. Epure stores up to 100 identical events a minute per error and 150 a minute per throw site, then counts every further occurrence without storing its payload. In the 20-per-second example, the issue still counts all 72,000 occurrences of the hour. A different error that starts during the loop gets its own allowance and appears as its own issue.

Your Sentry SDK stays: you change the DSN, and your beforeSend rules keep working because they run in the SDK. The rate is the same on every plan. The spike valve page explains the mechanism and its limits, and the error storm simulator shows what a flood you describe would store and count. Past the monthly quota, Epure Cloud keeps counting existing issues and stores the first event of each new or regressed issue, up to a grace of 5% of the quota (over-quota rule).

Sentry still wins on scope. Epure is in Beta and tracks errors only, with no tracing, replay, profiling or logs, and no mobile symbolication. Sentry's grouping is older and more tuned, and its spike protection also covers spans and attachments. If you rely on those, stay on Sentry and use the filters above.

How do you keep an error loop from coming back?

Error loops come back through the same few code paths, so prevention is a short review checklist plus one alert that fires on a sudden rise in volume. A retry policy of 3 attempts with a growing delay covers most network loops. Sentry's issue alerts can notify you when an issue escalates. Epure alerts fire on a new issue, a regression or a velocity spike, so a loop is flagged before the quota email arrives.

• Give every retry loop a maximum attempt count and a growing delay.
• Wrap React trees in an error boundary, and never set state unconditionally in useEffect.
• Log expected operational failures, such as rate limits and connection resets, at warning instead of error when an SDK integration captures log calls.
• Tag each deploy with a release value, so a temporary filter can target one release and be deleted with it.

Why is the error still flooding Sentry after the fix shipped?

A browser error can keep flooding Sentry after the fix ships, because tabs opened before the deploy still run the old bundle until they reload. Check the release tag on the newest events. If they all carry the old release, such as web@1.42.0, the fix works and the tail fades as tabs close; drop that release in beforeSend for a few days, or use Sentry's release filter on Business and Enterprise. If new events carry the new release, the loop has a second cause, and the fingerprint check starts again.