Sentry inbound filters drop SSR errors from AI agents and web crawlers

Building a site whose primary readers are AI agents and crawlers, we expected SSR errors experienced by that traffic to show up in Sentry. They never did: the project's error stream stayed near-empty while the outcomes API (stats_v2, outcome=filtered) showed a steady web-crawlers reason series quietly eating ~20% of what would have been the project's errors, plus transactions and spans. Nothing in the SDK config filters these; before_send never saw the events. We initially assumed the drops were our own inbound transaction-name filter or something UA-specific in our middleware, and only found the cause by reading which inbound filters Sentry enables by default on JS projects and what its crawler regex actually matches.

Sentry's web-crawlers inbound filter (default ON for new JS projects) drops events server-side at relay, before storage — invisible to the SDK, before_send, and the issue stream; only the outcomes API shows the loss (outcome=filtered, reason=web-crawlers).

The match list (relay-filter/src/web_crawlers.rs in getsentry/relay) is decisive if your audience includes AI agents:

Banned: ClaudeBot, GPTBot, OAI-SearchBot, PerplexityBot, CCBot, meta-*, facebook, plus a generic bots?([/\s\);]|$) rule that catches ANY user agent containing a standalone "bot" token (case-insensitive) — so Claude-SearchBot, Twitterbot, and most custom *bot fetchers are all dropped.
Allowlisted (exempt even though they match): only ChatGPT-User, Slackbot 1.x, and SentryUptimeBot.
Claude-User (Anthropic's user-initiated fetcher, the direct analog of ChatGPT-User) passes only by accident — it lacks the substring "bot". It is not on the allowlist, so a future rename could silently start dropping it.

Consequence: for any product where agent/crawler-experienced breakage is real user breakage (agent-facing docs, MCP-adjacent web surfaces, SEO-critical SSR), the default filter hides exactly the errors you care about. An SSR 500 served to ClaudeBot or GPTBot never reaches Sentry.

Fix via the project filters API (no UI needed):

PUT /api/0/projects/{org}/{slug}/filters/web-crawlers/    {"active": false}
PUT /api/0/projects/{org}/{slug}/filters/legacy-browsers/ {"subfilters": ["ie", "opera_mini"]}

(legacy-browsers defaults to all eight subfilters including chrome and android, which also drops outdated-Chrome/WebView errors; narrow it rather than disabling.) Both return 204; GET .../filters/ confirms. Quota impact is usually small — measure first with:

GET /api/0/organizations/{org}/stats_v2/?statsPeriod=30d&interval=1d&field=sum(quantity)&groupBy=reason&groupBy=category&outcome=filtered&project={id}

Verification signal after the change: the filtered/web-crawlers series goes to zero and crawler-visible SSR failures start appearing as normal issues.