suppressing-noisy-errors

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

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.

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:

The canonical exception properties ($exception_types, $exception_values, $exception_sources, $exception_functions) are arrays at capture time. PostHog's property filters special-case them — each filter matches against the individual array elements, so all the standard operators (exact, is_not, icontains, not_icontains, regex, not_regex) work with the bare value: exact "TypeError", not exact '["TypeError"]' or regex '"TypeError"'.

The singular forms ($exception_type, $exception_message) and $exception_stack_trace_raw are emitted on a fraction of a percent of events; filtering on them produces a rule that silently never matches.

Note that the regex operator on suppression and grouping rules compiles to the HogVM Operation::Regex, which is case-sensitive. Use the (?i) inline flag for case-insensitive matching (e.g. (?i)headlesschrome).

For matching multiple bot or crawler terms, use bare pipes for alternation. Pass this as the value field of the regex filter when calling the API ($raw_user_agent is more reliable than the parsed $user_agent, which some parsers normalize away from crawler markers):

(?i)(HeadlessChrome|bot|crawler|spider)

Whenever possible, AND together two or more conditions — type plus message, or message plus URL pattern — so the rule is specific to the real noise.

If you want to keep some visibility, use sampling_rate between 0 and 1:

• sampling_rate: 1 — drop everything matching (full suppression)
• sampling_rate: 0.95 — drop 95% of matching events, keep 5% as sentinel data
• sampling_rate: 0.5 — half-rate, useful for high-volume but real errors

Default to a non-1.0 sampling rate when there's any doubt that the pattern is purely noise. You can tighten to 1.0 later once the data shows the rule isn't catching real issues.

Before asking for confirmation, run the candidate filter against the issues list so you (and the user) can see exactly which issues the rule would have caught over the last 7 days. query-error-tracking-issues-list accepts the same property-filter shape suppression rules use via its filterGroup parameter, so for a typical AND-only rule you can pass the rule's leaf filters directly — no HogQL translation needed:

posthog:query-error-tracking-issues-list
{
  "filterGroup": [
    { "type": "event", "key": "$exception_types", "operator": "exact", "value": "Error" },
    { "type": "event", "key": "$exception_values", "operator": "icontains", "value": "ResizeObserver loop" }
  ],
  "dateRange": { "date_from": "-7d" },
  "status": "all",
  "filterTestAccounts": false,
  "orderBy": "occurrences",
  "limit": 25
}

Important defaults to override for suppression preview:

• status: "all" — suppression applies regardless of issue status, so don't let the default active filter hide already-archived noise.
• filterTestAccounts: false — the rule will not respect the test-account toggle at ingestion. The preview should match production reality.

Each row is one issue the rule would catch: name (exception type), description (sample message), source, library, plus aggregations.occurrences and aggregations.users. The issue list is the per-issue breakdown — read every row.

The single most important safety check: scan the result for any issue whose name / description / source looks like a real bug the team would want to fix, not noise. A filter that looks tight by message text will routinely match unrelated issues that happen to share a phrase, and this is the failure mode that silently destroys real data once the rule is live. If you see anything suspicious, narrow the filter (step 3) and rerun this step until only the genuine noise pattern is in the list.

Add up aggregations.occurrences and aggregations.users across rows for the blast-radius totals you'll surface to the user in step 6. If you need exact totals across more than limit issues, paginate with offset or fall back to the HogQL aggregate at the end of this step.

For one or two concrete sample events with full stack traces, follow up on the most suspicious-looking issue with query-error-tracking-issue-events:

posthog:query-error-tracking-issue-events
{
  "issueId": "<id from the list>",
  "limit": 3,
  "include": ["exception", "stacktrace", "environment", "navigation"],
  "onlyAppFrames": false
}

filterGroup is flat AND only. Drop into HogQL when:

• The rule uses type: "OR" at the outer group or any nested OR.
• The rule uses operators not supported by filterGroup (e.g. between, in, semver_*).
• You want a precise event-level count rather than per-issue aggregates.

The HogQL shape mirrors what the suppression rule bytecode compiles to. The materialized property column is nullable, so the coalesce(..., '[]') wrapper is required — without it ClickHouse rejects the query with "Nested type Array(String) cannot be inside Nullable type":

SELECT
  count() AS matched,
  count(DISTINCT distinct_id) AS users,
  count(DISTINCT properties.$exception_issue_id) AS issues
FROM events
WHERE event = '$exception'
  AND timestamp > now() - INTERVAL 7 DAY
  AND arrayExists(
    v -> ifNull(ilike(v, '<pattern>'), 0),
    JSONExtract(coalesce(properties.$exception_values, '[]'), 'Array(String)')
  )

Use ilike for icontains, plain equality for exact, match(v, '<pattern>') for regex. The rule's regex is case-sensitive — add (?i) inline if needed.

Suppression is destructive in spirit even though the API marks it destructive: false. Show the user before creating:

1. The exact filter you plan to send
2. The list of issues from step 5 with their occurrences and users, plus the aggregate totals — call out any rows that look like real bugs
3. Whether it overlaps any existing suppression rules (posthog:error-tracking-suppression-rules-list first)

Wait for explicit confirmation. Then create:

posthog:error-tracking-suppression-rules-create
{
  "filters": {
    "type": "AND",
    "values": [
      {
        "type": "event",
        "key": "$exception_types",
        "operator": "exact",
        "value": "Error"
      },
      {
        "type": "event",
        "key": "$exception_values",
        "operator": "icontains",
        "value": "ResizeObserver loop"
      }
    ]
  },
  "sampling_rate": 0.95
}

Start at 0.95 (drop 95%, keep 5% as sentinel data) so you can confirm the rule isn't catching real errors before tightening to 1.0.

After creating the rule:

• Confirm matching events are no longer being captured by running the same filter against a short window scoped to after the rule was created (e.g. WHERE timestamp > now() - INTERVAL 1 HOUR once an hour has passed). Don't re-run the 7-day estimate from step 5 — suppression only applies to new events, so historical events in the window will still be there and the count won't drop.
• Watch related active issues over the post-creation window — if their volume drops while non-related issues hold steady, the rule was scoped correctly
• If a related real issue's volume drops too (false-positive), ask the user to disable the rule via Project settings → Error tracking → Suppression rules immediately and tighten the filter before re-creating it. The MCP tools to edit or delete a rule (error-tracking-suppression-rules-partial-update, -destroy) are not enabled — the agent has no way to recover programmatically.

If you see signs of false positives (a real issue going quiet at the same time the rule was created), prefer disabling the rule over deleting it — that preserves the rule's configuration for forensic review.