/suppressing-noisy-errors

name: suppressing-noisy-errors
description: >
  Create PostHog error tracking suppression rules to drop high-volume,
  low-value errors at ingestion. Use when the user asks "stop capturing
  this error", "drop browser extension errors", "ignore ResizeObserver
  loops", "suppress bot-driven errors", or wants to reduce ingestion
  cost from noisy unactionable errors. Identifies suppression
  candidates, scopes the filter tightly, decides between full
  suppression and sampling, and confirms the rule before creating it.
  Suppressed errors are dropped permanently — this skill defaults to
  caution.

Suppressing noisy errors

Suppression is destructive in spirit: matching events are dropped at ingestion and never become issues. The wrong rule silently throws away real bugs. This skill exists to make sure suppression is applied only to patterns that are genuinely unactionable, with filters narrow enough to avoid swallowing unrelated errors.

When suppression is the right tool

Suppression is the right tool when an error is:

• **Unactionable from your code** — browser extensions, third-party scripts, ad

blockers, network beacons firing after navigation. You can't fix it because you didn't write it.

• **Browser engine quirks** — `ResizeObserver loop limit exceeded`,

`Script error.`, `Non-Error promise rejection captured` with empty payloads.

• **Bot or crawler traffic** — errors firing only from headless browsers or known

crawler user agents.

• **Sampling already enough** — for high-volume but real errors, dampen with

`sampling_rate` instead of full suppression so you keep visibility without paying full cost.

Suppression is **not** the right tool when:

• The error is unactionable _today_ but might become actionable after a fix —

use issue status `archived` or `resolved` instead so it surfaces if it returns.

• You only want to mute notifications — assign the issue to a user, change its

status, or use notification rules.

• The error is a duplicate of another — merge or create a grouping rule

(`grouping-noisy-errors`).

Available tools

| Tool | Purpose | | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | `posthog:query-error-tracking-issues-list` | Find suppression candidates by volume and impact; dry-run a candidate filter via `filterGroup` | | `posthog:query-error-tracking-issue-events` | Inspect sampled `$exception` events to confirm the pattern | | `posthog:execute-sql` | Fallback dry-run for filters that need OR groups or operators outside the `filterGroup` allowed list | | `posthog:error-tracking-suppression-rules-list` | Check existing suppression rules | | `posthog:error-tracking-suppression-rules-create` | Create the suppression rule | | `posthog:error-tracking-issues-partial-update` | Hide past data via issue status without dropping events at ingestion |

Workflow

Step 1 — Identify candidates

High occurrences with low distinct users is the strongest noise signal — one user (or one bot) producing many events.

posthog:query-error-tracking-issues-list
{
  "status": "active",
  "orderBy": "occurrences",
  "orderDirection": "DESC",
  "dateRange": { "date_from": "-7d" },
  "limit": 30,
  "volumeResolution": 0
}

Look for:

• High `occurrences`, low `users` ratio (e.g., 50,000 occurrences, 3 users → likely

bot or extension loop)

• Exception messages matching known noise patterns: `ResizeObserver loop`,

`Script error.`, extension namespaces (`chrome-extension://`, `moz-extension://`, `safari-extension://`)

• Stack traces dominated by third-party domains the user doesn't control

Step 2 — Confirm the pattern

For each candidate, pull a sample of `$exception` events and check that the pattern matches what you intend to suppress:

posthog:query-error-tracking-issue-events
{
  "issueId": "<candidate_issue_id>",
  "limit": 10,
  "include": ["exception", "stacktrace", "environment", "navigation"]
}

`onlyAppFrames` defaults to `true`, but for noise investigation you usually want the third-party frames visible — pass `onlyAppFrames: false` so extension URLs and vendor domains show up in the stack.

Confirm:

• The exception type or message text is consistent across the sample
• The URLs / user agents / browsers don't include real user traffic mixed in with

the noise

• Suppressing this pattern won't hide a future real bug that happens to share

the type

If any sample doesn't match, narrow the filter or skip the candidate.

Step 3 — Scope the filter tightly

Suppression rules are configured with the same filter shape as grouping rules. The `error-tracking-suppression-rules-create` tool description warns explicitly: do **not** create match-all rules and do **not** create overly broad rules. Match on the most specific property combination you can:

| Noise pattern | Recommended filter | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | Chrome extension errors | `$exception_sources icontains "chrome-extension://"` | | Firefox extension errors | `$exception_sources icontains "moz-extension://"`