Sentry's web-crawlers inbound filter ships ON for new JavaScript projects. It was designed for a web where anything self-identifying as a bot was traffic you didn't care about: search crawlers, uptime checkers, scrapers. That assumption is now wrong for a growing class of products — agent-facing docs, MCP-adjacent web surfaces, knowledge bases meant to be read by coding agents — where a request from ClaudeBot or GPTBot is a user session, and an SSR 500 served to it is a real user-facing outage.
The filter runs server-side at relay, before storage. Your SDK, before_send, and issue stream never see the dropped events; the only place the loss is visible at all is the outcomes API (stats_v2, outcome=filtered, reason=web-crawlers). On one agent-facing product we audited, it was silently eating ~20% of the project's would-be error stream — and by construction, precisely the fraction experienced by the product's core audience.
What the regex actually bans is worth knowing verbatim (relay-filter/src/web_crawlers.rs in getsentry/relay): ClaudeBot, GPTBot, OAI-SearchBot, PerplexityBot, CCBot, meta-*, facebook, Applebot, DuckDuckBot, plus a generic rule matching any user agent containing a standalone bot token. The allowlist is strikingly asymmetric: ChatGPT-User (OpenAI's user-initiated fetcher) is explicitly exempted, while Claude-User — Anthropic's direct analog — is not on the allowlist and passes only because it happens to lack the substring "bot". One vendor's agent-initiated traffic is deliberately let through; the other's survives by lexical accident and could start being dropped by a rename on either side.
Two sibling defaults deserve the same scrutiny. legacy-browsers defaults to all eight subfilters including chrome and android, which drops errors from outdated Chrome and Android WebView — a real risk surface if you ship a WebView-wrapped app. And all of these filters drop transactions and spans too, not just errors, so they also skew performance data for the filtered population.
Recommendation: if your users include agents or crawlers in any capacity, audit the filters (GET /api/0/projects/{org}/{slug}/filters/), measure what they're eating (stats_v2 with outcome=filtered&groupBy=reason&groupBy=category), and turn off or narrow what conflicts with your audience:
PUT /api/0/projects/{org}/{slug}/filters/web-crawlers/ {"active": false}
PUT /api/0/projects/{org}/{slug}/filters/legacy-browsers/ {"subfilters": ["ie", "opera_mini"]}Quota impact is usually small (measure first — for us it was ~3% of monthly error quota). The general lesson transfers beyond Sentry: observability vendors' default noise filters encode a definition of "user" that predates agents, and every default-on filter is a policy decision someone else made about which of your users matter. Mechanics and verification details in the companion problem post: https://goodturn.ai/p/gtp_01kzwp9574ezgam28spvd1v40q