Sentry — Overview

Your app is live. Real users are using it. You're sleeping.

At 2am, something breaks. A user sees a white screen. They try refreshing. Still broken. They give up and close the tab.

You wake up the next morning with no idea any of this happened.

---

The "Why First" Scenario

Imagine this plays out twice — once without Sentry, once with it.

Without Sentry

A parent on your client's school app tries to complete their fee payment. The button does nothing. The screen goes white. There's no error message — just silence.

The user assumes the app is buggy. They don't report it. They book with a competitor instead.

Two weeks later, your client notices retention numbers dropping. They ask you why. You check your code. You check Supabase. Nothing obvious. You have no idea when this started, which users were affected, what triggered it, or which component failed. You're debugging blind, weeks after the fact, with no evidence.

The client starts wondering whether they made the right choice hiring you.

With Sentry

The same user hits the same broken button. In the same millisecond, Sentry captures the error invisibly in the background. You receive an email within 60 seconds:

New Issue: TypeError — Cannot read properties of undefined (reading 'id') Component: FeePaymentConfirmation.tsx — line 47 User: Ramesh K, ramesh@example.com Device: iPhone 13, Safari 16 What the user was doing: Opened fee page → selected fee → tapped Pay → crash First seen: 2:14am | Occurrences so far: 3

You see the error before your client's morning coffee. You fix it, deploy, and send your client a message:

"Caught a bug in the fee payment flow — fixed and live at 6am. Three users were affected. No data loss."

That message, sent proactively, is worth more than months of delivering features on time. It tells the client: you're on top of things even when you're asleep.

That is what Sentry does.

---

The CA Analogy

In auditing, you keep a complete trail of every transaction — who did what, when, what the state was before and after, and what triggered each change. If something goes wrong months later, you open the audit trail and reconstruct exactly what happened.

Sentry is the audit trail for your app's behaviour.

Every error is logged with full context: which function threw it, what data it was processing, what the user had done in the previous 10 seconds, which device and browser they were on, which version of your code was running. You can reconstruct a crash in perfect detail — even one that happened at 2am on a user's phone you've never seen.

Without this trail, debugging production errors is guesswork. With it, most bugs are obvious in under 5 minutes.

---

What Sentry Captures

JavaScript Exceptions

Any unhandled error that occurs in your React app — a TypeError, a missing .map() on undefined data, a network call that failed and wasn't caught — Sentry intercepts it automatically. You didn't write any extra code to catch these. Sentry wraps your app and captures anything that slips through.

API / Network Failures

When a call to your Supabase backend fails — an auth error, a database query that times out, a storage upload that rejects — Sentry can log this as a performance event, showing you which endpoints are failing and how often.

Performance Data

Sentry measures how fast your pages load in real users' browsers. It tracks Core Web Vitals: LCP (how quickly the main content appears), CLS (whether things jump around while loading), and INP (how fast the app responds to clicks). This is the same data Google uses to rank your site in search results.

If a page starts loading slowly after a deploy — you'll see it in Sentry before users start complaining.

User Context

Sentry knows which user triggered the error, because you tell it after login:

When a bug only affects one specific user, you can filter to their errors and see exactly what they were doing. Instead of "something broke for someone", you get "this specific user on this specific device hit this specific bug in this component."

Release Tracking

Sentry knows which version of your code is running — the "release". When a new bug appears, Sentry flags it: "First seen in release v1.4.2". When you fix it, Sentry confirms: "Resolved in v1.4.3". You can see at a glance which bugs came from which deploy, and whether a fix actually worked.

---

Why Production is Different From Development

When you build locally, errors appear in the browser console immediately. You see them. You fix them.

In production:

• Users don't open the browser console
• You're not watching when errors happen
• Errors happen on devices you don't own, on networks you can't test
• Some bugs only appear with real data (data you don't have locally)
• Some bugs only appear at scale (when multiple users are using the app simultaneously)

Without Sentry, production errors are invisible unless a user bothers to report them — and most don't. Studies consistently show that for every user who reports a bug, five others gave up silently.

Sentry makes the invisible visible.

---

The Free Tier Is Enough for Everything in This Workshop

Sentry's free plan includes:

• 5,000 errors per month
• 10,000 performance events per month
• 14 days of error history
• 1 team member (your account)
• All core features: issues, releases, alerts, breadcrumbs, stack traces

This covers all training projects, CA firm websites, and Finpist comfortably. For EduTrack, you may upgrade as traffic grows — but during development and early launch, free is sufficient.

---

What You'll Have After This Section