Why we built a 200-line error tracker instead of adopting Sentry right away

The core choice

Instead of adopting Sentry right away, we built a custom client-side error tracker at roughly 200 lines. We judged that saving the time needed for approval and adoption, and securing the minimum operational reliability needed right now, was the more realistic path.

• Collection: window.error, Promise rejections, React Query failures, Axios 5xx
• Aggregation: tracking how many times the same error recurs
• Alerts: sending a Slack Webhook when a threshold is exceeded
• Spam prevention: once an error has triggered an alert, no re-alert for a set period

Implementation

Errors are collected via reportError from both the browser and WebView, a fingerprint is generated, and the data is sent to a Supabase Edge Function. The Edge Function stores it in Postgres, and only sends a Slack alert once the cumulative count exceeds the threshold.

To group the same bug as the same bug, we normalized the stack trace and then applied an FNV-1a 32-bit hash. Elements that change with every deploy, like line·col and bundle hashes, are stripped out first, so that even when minified function names differ, they're still aggregated as the same issue.

Operational criteria

Thresholds and cooldowns live inside an RPC function in the DB, not on the client. To change the numbers, you just edit them in the SQL Editor, so alert policy can be adjusted without redeploying.

Source map symbolication, breadcrumbs, automatic User ID injection, a custom dashboard, and automatic issue-tracker creation were all excluded. Rather than adding more things to manage, the focus was on keeping only what's actually needed so the tool doesn't eat into the core work.

Results in practice

Before going to production, we ran QA on dev/stage for over a month, and recently completed the production deployment. However, since the production sample size isn't sufficient yet, the observations below are organized mainly around dev/stage data.

Over 3 weeks, only 1 fingerprint exceeded the threshold of 5 times in 7 days. Most errors were one-off events like temporary network disconnects, ad SDK failures, and quick bounces, and lowering the threshold to 1 to look at the raw data made that tendency even clearer.

The one case that did exceed the threshold was a bug that only occurred on a specific OS + WebView combination. Because device/browser/platform metadata was stored alongside it, narrowing down the cause was fast.

There were shortcomings too. We didn't include a build SHA from the start, which made it hard to pinpoint the exact deploy where a regression began — that item is now a higher priority. It's not a tool that catches every single error perfectly, but it does provide enough visibility to not miss recurring client-side errors.