Sentry SDK 2.x Auto-Integrations Flood Your Inbox — Here's the Filter

HoneyChat, a Telegram-native AI companion with approximately 300 daily active users, experienced a surge from roughly 5 Sentry issues per day to over 4,000 after upgrading from Sentry SDK 1.x to 2.x. The upgrade automatically enabled integrations for Loguru, OpenAI, SQLAlchemy, asyncpg, Redis, and httpx, flooding the inbox with expected operational errors like rate limits, connection resets, and retry exceptions rather than actual bugs. The team implemented a `before_send` filter that suppresses known operational exceptions and logger-specific noise while still reporting genuine errors.

A clean Sentry inbox is a load-bearing developer tool. The day yours starts showing 4,000 events for things that aren't bugs, you stop opening it. The day after that, you miss the real bug. We upgraded HoneyChat https://honeychat.bot/ — Telegram-native AI companion, ~300 DAU — from Sentry SDK 1.x to 2.x and that's what happened. The SDK gained a useful new behavior: it auto-enables a set of integrations whenever it detects the relevant library imported. Loguru, OpenAI, SQLAlchemy, asyncpg, Redis, httpx — all on by default in 2.x. No more integrations= ... boilerplate. This is great when those integrations capture only real errors. They don't. HoneyChat backend stack for context : aiogram Telegram polling bot bot/main.py api/main.py , uvicorn --workers 4 llm , images , gifs , voice workers/tasks.py gen worker image/GIF generation queue openai Python SDK base url swapped to https://openrouter.ai/api/v1 — so openai. exception types fire on OpenRouter responses tooThat stack imports every library the Sentry 2.x auto-integration looks for. They all turn on. Within a day of the upgrade: logger.error "…" from Loguru error -level openai.RateLimitError and openai.APIConnectionError tenacity retries. Not bugs. asyncpg /SQLAlchemy pool race bot , api , celery worker , nginx back-to-back during a full release; pool reconnects produce a brief flurry of these. Not bugs. ConnectionResetError Real bugs were drowning. Issue counts went from ~5/day to 4,000+. Sentry SDK 2.x scans sys.modules at init and turns on any integration whose target library is already imported. The relevant docs page lists them. Three matter most for a typical Python service: LoguruIntegration — captures Loguru records at ERROR and above. OpenAIIntegration — captures all openai.OpenAIError raises which, for us, includes everything OpenRouter ever returns through the OpenAI SDK . SqlalchemyIntegration — captures slow queries, connection errors, and a few other states.You can disable individual integrations: python import sentry sdk from sentry sdk.integrations.loguru import LoguruIntegration from sentry sdk.integrations.openai import OpenAIIntegration sentry sdk.init dsn=settings.SENTRY DSN, disabled integrations= LoguruIntegration, OpenAIIntegration, , …but that's a blunt instrument. We do want LLM errors reported when they're real. We want Loguru-routed errors reported when the line that produced them is actually a bug. The fix is a before send filter. core/sentry filters.py python import sentry sdk from sentry sdk.types import Event, Hint EXPECTED EXCEPTIONS = "openai.RateLimitError", "openai.APIConnectionError", "openai.APITimeoutError", "openai.InternalServerError", "redis.exceptions.ConnectionError", "redis.exceptions.TimeoutError", "asyncpg.exceptions.ConnectionDoesNotExistError", "asyncpg.exceptions.InterfaceError", "sqlalchemy.exc.OperationalError", OPERATIONAL LOGGERS = "core.llm", fallback chain, content filter rescue, retries "core.image gen", GPU → API provider switchover "core.voice", Inworld TTS → gTTS fallback "workers.gen worker", task-level fallback def before send event: Event, hint: Hint - Event | None: exc info = hint.get "exc info" if exc info: exc type = exc info 0 exc path = f"{exc type. module }.{exc type. name }" if exc path in EXPECTED EXCEPTIONS: return None logger name = event.get "logger" or "" if logger name in OPERATIONAL LOGGERS: level = event.get "level" if level in "error", "warning" : return None return event sentry sdk.init dsn=settings.SENTRY DSN, before send=before send, traces sample rate=0.0, profiles sample rate=0.0, The filter is twenty lines. The two tuples are the actual contract: these exceptions and these loggers are noise. After deploying this, Sentry inbox went from 4,000+ to ~30 events/day. The 30 included two real bugs we'd been missing. A filter is half the answer. The other half is fixing the log levels at the source. Our team now follows three rules: logger.error ... logger.warning ... logger.info ... A normal-path "Gemini returned content filter, falling back to Grok 4.20" is info , not error . The terminal might lose some red, but Sentry stops crying wolf. When we audited our codebase against this, we found roughly 40 logger.error lines in core/llm.py , core/image gen.py and workers/gen worker.py that should have been warning or info . Fixing them at source means the before send filter doesn't need to grow indefinitely. We considered ignore errors= ... on sentry sdk.init instead of a before send . The problem is that ignore errors only matches by exception type name , not module path. ConnectionError is ambiguous Redis vs httpx vs asyncpg — all have one . The fully-qualified path check in before send is more precise. We also considered turning the integrations off entirely. The risk is losing visibility into real LLM and DB errors — when there's a real bug in the LLM path, the OpenAIIntegration 's stack-trace enrichment is genuinely useful. Keeping the integrations on and filtering precisely was the better trade. before send is the right hook for noise reduction. error doesn't mean "Sentry-worthy", your Sentry inbox is broken.The hardest part of this work isn't the filter — it's getting the team to agree on what error actually means. This filter runs in production at HoneyChat — Telegram-native AI companion bot. Canonical version: — HoneyChat Engineering disabled integrations . before send filtering None to drop, mutate to scrub. base url setup with OpenAI SDK openai. exception types fire on OpenRouter responses.