tgolab
PLEN
All projects

~/tgolab/projects $ cat raportowanie-bledow.md

Error reporting

Landingi

From an unused Sentry to a process where reporting is the default: full context for every error and the noise filtered out.

Alert bell next to an error chart crossing its threshold
SPA app issues in Sentry with trend and affected users
EventTracker issues in Sentry
Error and metric monitors in Sentry
Sentry alert rules with Slack and email notifications
1 / 5

Problem

Sentry was set up in the project but barely used: frontend errors weren’t reaching it, and the team learned about production failures from customers.

My role

Bringing order to error handling across the whole SPA and building a tool that made reporting the default behaviour rather than extra work.

What I built

  • A custom reporting function that makes logging frontend errors simple. It is hooked into every data fetch from the backend and sends the error code with the full context needed for debugging.
  • Enriching events with context: user, app version, release and breadcrumbs.
  • Filtering out noise: silencing errors from browser extensions, bots and ResizeObserver, so only events worth acting on reach Sentry.
  • Alerts and error monitoring in Sentry for many projects, several of which I manage day to day.

Outcomes

  • Production errors are caught sooner, in some cases before a customer reports them.
  • Faster debugging: every report contains everything needed up front, with no need to reproduce the issue locally.
  • Fewer tickets reaching support.