About Supabase
Supabase is the easy-to-use, open-source managed Postgres with integrated backend services: write SQL, deploy Edge Functions, and ship production applications. At the center of every Supabase project is Studio, the web dashboard maintained by their frontend team. When Studio breaks, developer workflows break. Behind it sits the platform (auth, APIs, workers, caching) that every project depends on. Both surfaces now run on the same monitoring backbone.
This is the story of how two teams got there.
Part one: the frontend team
A Sentry project nobody trusted
By late 2025, Supabase’s Sentry project was in the state every frontend team eventually reaches with an untended error inbox: full of noise the team had learned to ignore.
A single user-cancellation bug was generating 466,797 events per week. The app was rethrowing user-cancelled operations as exceptions, so every Cancel button click became a Sentry event. Browser wallet extensions injecting scripts added another ~7,500 weekly events. Aborted sign-ins and expired captchas piled on top.
Roughly 475,000 weekly events of pure noise, drowning every real bug underneath.
“We were shocked that we had zero alerts pop up for FE.”
— Ali Waseem
When Studio had a frontend outage in February 2026, not a single Sentry alert fired. Worse: a config issue had silently stopped Sentry from capturing frontend errors for a four-week stretch before that, and nobody had noticed.
Fixing signal before fixing bugs
The frontend team rebuilt their Sentry setup in deliberate order: noise first, bugs second, tracing third, alerts fourth.
The first move was implementing beforeSend filtering directly in the SDK rather than relying on Sentry-side data filters. Events filtered in beforeSend never leave the browser, so they don’t count against quota and don’t pollute the project at all. The filter config lives in version control, reviewed like any other code change. They also fixed the biggest noise source at its root by stopping the rethrow of user cancellations as exceptions.
Three weeks later: weekly crashes dropped from 2,000+ to 32.
With a clean inbox, the team used Sentry’s user-impact ranking to work the remaining issues in priority order. Five high-impact bugs were discovered and fixed, retiring ~115,000 events and unblocking ~6,300 users. One of those bugs had been in production for six months without a single customer ever escalating it.
“Surprisingly Seer is very good at finding root causes. You can have Claude call Seer as a sub-agent to help diagnose issues faster.”
— Ali Waseem
To keep the project from decaying, the team uses Seer for root-cause analysis on new issues, sometimes via Sentry directly and sometimes as a sub-agent inside Claude Code. Specialized Claude skills auto-classify new browser-extension noise and route it to the ignore list, so the inbox stays clean without manual gardening.
Tracing and alerts that actually fire
The team rolled out distributed tracing across Studio, giving them end-to-end visibility from frontend to Supabase’s backend APIs. A 24-hour snapshot after rollout: 7.18M transactions/day, 630K pageloads, 6.2M navigations, and per-endpoint latency data for every path Studio takes through the backend.
“Spans are enabled so we can see detailed request volume from the front end app to the backend. Those spans now have a ton of monitors for zero throughput and abnormal volumes.”
— Ali Waseem
With trustworthy error and traffic signals in place, the team built alerts that actually meant something: error-rate anomaly detection, crash-free sessions dropping below 99.5%, chunk loading failures, and critical-path alerts scoped to the Table Editor and auth flows. All routed to #team-frontend-alerts.
The alerts proved themselves quickly. Within weeks, the team detected backend issues (auth, API) twice before the owning teams did, handing off specific signal: route, error code, user impact.
“Our alerts are continuing to capture instabilities in the dashboard. Found one today regarding 500s and let auth and api team know about the issues.”
— Ali Waseem
Part two: the backend team
Those frontend alerts landing on the auth and API teams weren’t a coincidence. On the platform side, Kamil Ogórek, a Supabase backend engineer and former Sentry SDK author, had been consolidating the backend’s fragmented tooling onto the same platform.
One place, correlated
Supabase’s existing stack gave the backend team logs and metrics, but they lived apart, not tied together by a trace. Debugging meant stitching context by hand, jumping between tools to line up timestamps.
“Sentry is the first product that gives us errors, logs, metrics, traces, and alerting in one place. We get an alert on an error from prod, and it already shows the logs interconnected by traces across services. It’s one source of truth for what’s broken, and that lets us debug fast.”
— Kamil Ogórek, Backend Engineer, Supabase
For a suspend-and-wake service that polls other services and collects logs at each hop, that correlation is the whole game. When one service errors, Sentry shows the full chain of actions and exactly where it connects to everything downstream, so the team focuses on what’s actually broken instead of reconstructing the sequence.
A recent Redis out-of-memory incident is the pattern in miniature: one instance got overwhelmed, and alerts fired across every endpoint that touched caching. Rather than chasing each endpoint, the team followed the correlated view to the common cause (the caching layer) and fixed it there.
Tail-based sampling, built their way
The backend team didn’t want Sentry’s default sampling. They wanted control over exactly which traces were worth keeping. So every trace now flows through an OpenTelemetry Collector running a custom tail-based solution before it reaches Sentry.
“All traces go through an OTel Collector with a custom tail-based solution before they reach Sentry. We send 100% of traces initiated by an error, always send anything slower than 10 seconds, and sample noisy services down to 2%. For async jobs we can extend the batching window up to two minutes, so a full trace (API, auth, worker) arrives as one complete picture.”
— Kamil Ogórek
The payoff isn’t just cost. Prefiltering upstream means far fewer traces reach Sentry, and the ones that do are the ones worth looking at.
“We send far fewer traces now because we prefilter before Sentry. That cuts cost, but the bigger win is less noise: more of what lands in Sentry is value-additive.”
— Kamil Ogórek
It’s the same principle the frontend team reached from the opposite direction: fix signal first, and everything downstream gets easier.
Alert once, escalate correctly
The backend workflow is built to stay quiet until it shouldn’t be. Sentry alerts on every new escalation-level issue and nothing more. Anything noisier would train the team to ignore it. Fatal errors take a second path.
“We alert on every new escalation-level issue; anything more would be too noisy. Fatal errors take a second path: they hit Slack and incident.io, triggering an on-call escalation right away. And with our GitHub integration, a PR that says ‘fixes’ the issue resolves it on the Sentry side automatically.”
— Kamil Ogórek
Sentry is the first thing that fires and the last thing they check: it opens the incident and, once the fix ships, confirms the issue is stable in production before the team closes it out.
Results
| Metric | Before | After |
|---|---|---|
| Weekly crash events (frontend) | 2,000+ | 32 |
| Weekly noise events (frontend) | ~475,000 | 0 (filtered in beforeSend) |
| High-impact bugs found via Sentry | 0 | 5, affecting ~6,300 users |
| Backend incidents caught before owning team | 0 | 2 (auth, API) |
| Trace pipeline (backend) | all traces sent, noisy | tail-based: 100% of error traces, slow traces always, noisy services at 2% |
| Customer tickets needed to find top bugs | All of them | 0 |
The shift showed up in how the rest of Supabase talked about the team. The clearest signal wasn’t a dashboard metric. It was an unprompted message in Slack from someone in support:
Monica, Support Engineer Extraordinaire at Supabase
That’s what happens when error monitoring stops being a second inbox and starts being where you find out about bugs before your users do — on both sides of the stack.
Try Sentry for free · See Seer in action · Read the docs on beforeSend filtering