> AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt

# Reduce noise – Error Tracking pocket guide

Canonical URL: https://posthog.com/learn/error-tracking/pocket-guide/reduce-noise

> **Cloud region:** This page uses US Cloud hosts. For an EU Cloud project, use `https://eu.posthog.com` instead of `https://app.posthog.com` (app host for links).

## On this page

- [Skip local development with production builds](#skip-local-development-with-production-builds)
- [Drop browser errors with before_send](#drop-browser-errors-with-before_send)
- [Stop looping browsers with burst protection](#stop-looping-browsers-with-burst-protection)
- [Drop extension errors with a suppression rule](#drop-extension-errors-with-a-suppression-rule)
- [Cap outages with rate limits](#cap-outages-with-rate-limits)
- [Triage noisy issues](#triage-noisy-issues)

Chapter 04

# Reduce noise – Error Tracking pocket guide

Twig is growing, and the engineers are starting to notice issues that are noisy, but they'll never fix. For example:

-   Exceptions from their own laptops during local development.
-   `ResizeObserver loop` errors the browser or React throws, which guests never notice.
-   One browser stuck in a loop, sending the same exception 15,000 times in an hour.
-   Errors from browser extensions, in code Twig doesn't own.
-   A flood of exceptions during an outage.

PostHog bills by events ingested, so these noisy events also cost money.

Here are the tools Twig's engineers use to silence noisy exceptions.

## Skip local development with production builds

Twig only starts PostHog in production builds. Local development builds don't capture events or exceptions:

```javascript
if (process.env.NODE_ENV === 'production') {
    posthog.init('<ph_project_token>', { capture_exceptions: true })
}
```

Local development environments are especially noisy, and many of the exceptions that happen in local development don't manifest in production at all.

## Drop browser errors with before\_send

The engineers drop the browser's `ResizeObserver loop` errors in Twig with the SDK's `before_send` hook, which runs before the SDK sends anything. It returns `null` to drop an exception, or edits its properties to redact sensitive data:

```javascript
posthog.init('<ph_project_token>', {
    before_send: (event) => {
        const exception = event.properties.$exception_list?.[0]
        if (exception?.value?.includes('ResizeObserver loop')) {
            return null
        }
        return event
    },
})
```

Nothing dropped here reaches PostHog, so it's the cheapest place to filter.

The ![](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/docs/integrate/js.svg) [web](https://posthog.com/docs/error-tracking/installation/web.md), ![](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/docs/integrate/nodejs.svg) [Node.js](https://posthog.com/docs/error-tracking/installation/node.md), ![](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/docs/integrate/react.svg) [React Native](https://posthog.com/docs/error-tracking/installation/react-native.md), ![](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/docs/integrate/ios.svg) [iOS](https://posthog.com/docs/error-tracking/installation/ios.md), ![](https://res.cloudinary.com/dmukukwp6/image/upload/Android_robot_bec2fb7318.svg) [Android](https://posthog.com/docs/error-tracking/installation/android.md), ![](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/docs/integrate/flutter.svg) [Flutter](https://posthog.com/docs/error-tracking/installation/flutter.md), ![](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/docs/integrate/kmp.svg) [Kotlin](https://posthog.com/docs/error-tracking/installation/kmp.md), ![](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/docs/integrate/python.svg) [Python](https://posthog.com/docs/error-tracking/installation/python.md), ![](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/docs/integrate/ruby.svg) [Ruby](https://posthog.com/docs/error-tracking/installation/ruby.md), and ![](https://res.cloudinary.com/dmukukwp6/image/upload/q_auto,f_auto/Roblox_Corporation_2025_logo_svg_301751b47c.png) [Roblox](https://posthog.com/docs/error-tracking/installation/roblox.md) SDKs all have a similar hook, and some name it `beforeSend`. [Suppressing exceptions](https://posthog.com/docs/error-tracking/capture.md#suppressing-exceptions) shows it for web and React Native.

## Stop looping browsers with burst protection

Burst protection in the ![](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/docs/integrate/js.svg) [web](https://posthog.com/docs/libraries/js.md) and ![](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/docs/integrate/nodejs.svg) [Node.js](https://posthog.com/docs/libraries/node.md) SDKs keeps a bug that loops in one guest's browser from flooding the project. It's on by default.

Burst protection only runs in those two SDKs, in the client. To cap volume from every SDK, the engineers use [rate limits](#cap-outages-with-rate-limits).

## Drop extension errors with a suppression rule

The engineers add a suppression rule in [Error Tracking settings](https://app.posthog.com/error_tracking/configuration#selectedSetting=error-tracking-suppression-rules) for errors from guests' browser extensions. It drops future exceptions that match its filters, like the exception type or message Fig. 1. PostHog applies rules at ingestion, and some SDKs apply them in the app too.

![The suppression rule editor: a match mode, a filter on exception type, and the types to drop](https://res.cloudinary.com/dmukukwp6/image/upload/suppression_rule_light_8db44eb6b1)

![The suppression rule editor: a match mode, a filter on exception type, and the types to drop](https://res.cloudinary.com/dmukukwp6/image/upload/suppression_rule_dark_5972d57398)

123

Fig. 1 – This suppression rule drops two exception types from now on.Hover over the figure to learn about each element.

## Cap outages with rate limits

Rate limits cap how many exceptions PostHog ingests during an outage. The engineers set a per-issue limit, so one noisy issue can't use up the whole project's limit. A project-wide limit caps the project's total volume.

Bypass rules let critical exceptions skip both limits. PostHog still bills the exceptions they let through.

## Triage noisy issues

When an issue gets noisy, Twig's engineers decide what to do with it like this:

%%{init: {"theme":"base","fontFamily":"RoundHog, sans-serif","themeVariables":{"fontFamily":"RoundHog, sans-serif","primaryColor":"#FFDCA3","primaryBorderColor":"#FFA81C","lineColor":"#1490E8"},"themeCSS":".node rect, .node polygon { fill: rgb(var(--accent)); stroke: rgb(var(--border)); stroke-width: 1.5px; } .node.check rect, .node.check polygon { fill: #FFA81C26; stroke: #FFA81C; } .node.act rect, .node.act polygon { fill: #1490E826; stroke: #1490E8; } .nodeLabel, .edgeLabel { color: rgb(var(--text-primary)); } .flowchart-link { stroke: rgb(var(--text-secondary)) !important; } .marker { fill: rgb(var(--text-secondary)) !important; stroke: rgb(var(--text-secondary)) !important; } .edgeLabel foreignObject { overflow: visible; } span.edgeLabel { background: transparent !important; } .yes, .no { background: rgb(var(--bg)); color: rgb(var(--text-primary)); padding: 0 3px; } .no { position: relative; left: 30px; }"}}%% %%{init: {"block": {"padding": 22}}}%% block-beta columns 3 issue\["Noisy issue"\] space space sensitive("Sensitive data?") space redact\["Redact in before\_send"\] fix("Will you fix it?") space assign\["Keep active and assign"\] key("Hits key customers?") space flag\["Flag for a human"\] loop("One client looping?") space burst\["Tune burst protection"\] known("Known type or message?") space rule\["Add a suppression rule"\] outage("Outage flooding it?") space limit\["Set a per-issue rate limit"\] suppress\["Suppress the issue"\] space space issue --> sensitive sensitive -- "<span class='yes'>yes</span>" --> redact sensitive -- "<span class='no'>no</span>" --> fix fix -- "<span class='yes'>yes</span>" --> assign fix -- "<span class='no'>no</span>" --> key key -- "<span class='yes'>yes</span>" --> flag key -- "<span class='no'>no</span>" --> loop loop -- "<span class='yes'>yes</span>" --> burst loop -- "<span class='no'>no</span>" --> known known -- "<span class='yes'>yes</span>" --> rule known -- "<span class='no'>no</span>" --> outage outage -- "<span class='yes'>yes</span>" --> limit outage -- "<span class='no'>no</span>" --> suppress class sensitive,fix,key,loop,known,outage check class redact,assign,flag,burst,rule,limit,suppress act

We turned this into a skill for you to triage your noisy issues Fig. 2. It asks for approval before it changes anything.

error-tracking-noise-audit/SKILL.md

```markdown
---
name: error-tracking-noise-audit
description: >
  Find noisy PostHog Error Tracking issues and propose the right control for each: suppression,
  rate limits, before_send, or leaving the issue active. Changes nothing without approval.
---

# Audit error tracking noise

Read the current docs first. Every PostHog docs URL returns Markdown if you append `.md`:

- https://posthog.com/docs/error-tracking/rate-limiting.md
- https://posthog.com/docs/error-tracking/capture.md (burst protection, suppressing exceptions)
- https://posthog.com/docs/error-tracking/managing-issues.md (issue statuses)

## Find candidates

Use the PostHog MCP. List the issues from the last 7 days with their exception count and the
number of people affected.

- High volume from a few people is usually a loop or one broken client.
- Volume spread across many people, with no frames from your own code, is usually browser
  extensions or third-party scripts.
- A sudden jump in one issue during an incident is an outage.

## Propose a control

Walk each candidate through these checks in order, and stop at the first yes:

1. Does it carry sensitive data? Propose a `before_send` hook that redacts it.
2. Is it a real bug someone will fix? Leave it active and suggest an owner.
3. Does it hit paying customers or a core flow like signup, login, or checkout? Flag it for a
   human. Never propose suppressing it.
4. Is one client throwing it in a loop? Check burst protection is on in web and Node.js, and propose
   tuning it. For other SDKs, propose a per-issue rate limit.
5. Can you describe it by exception type or message, like a browser extension error? Propose a
   suppression rule.
6. Is an outage flooding it? Propose a per-issue rate limit.
7. Otherwise, propose suppressing the issue.

## Rules

1. Ask before you suppress an issue, add a suppression rule, or change a
   rate limit.
2. Suppressed and rate-limited exceptions are dropped for good. Say so in each proposal.
3. Before you tighten rate limits, propose bypass rules for exceptions that must always arrive.

## Finally

Return a table with the issue, exception count, people affected, what you think the noise is, the
control you propose, and why.
```

Show full example

Fig. 2 – The skill Twig's engineers use to find noisy issues and pick a control for each. Copy it and give it to your agent.

[Querying exceptions →](https://posthog.com/learn/error-tracking/pocket-guide/querying-exceptions.md)

**Explore further**

[Rate limiting](https://posthog.com/docs/error-tracking/rate-limiting.md)