How Supabase’s frontend team cut weekly crashes by 60x and started catching bugs before customers
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.
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
Results
| Metric | Before | After |
|---|---|---|
| Weekly crash events | 2,000+ | 32 |
| Weekly noise events | ~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) |
| 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.
Try Sentry for free · See Seer in action · Read the docs on beforeSend filtering