What is it?
Once a site is live, you need to know when it breaks — before users tweet about it. Error monitoring (Sentry) captures exceptions with stack traces and context. Analytics (Vercel, Plausible, PostHog) tracks real-user performance and behavior. Together they turn "a user said it's broken" into "here's the exact error, browser, and line."
Why it matters
The gap between junior and mid-level is often "do you know what happens after deploy?" Shipping is half the job; knowing your error rate, your real LCP, and your most-broken page is the other half. Teams notice candidates who think past the merge button.
What to learn
- Error monitoring: Sentry setup, source maps, release tracking
- What context to capture: user, browser, breadcrumbs, state
- Real-user monitoring (RUM): field Core Web Vitals
- Product analytics: events, funnels, where users drop off
- Error budgets and alerting — when to wake someone up
- Privacy: what you can and can't track (GDPR, consent)
Common pitfall
Logging errors to the console and calling it monitoring. Console logs die with the user's tab. Real monitoring sends errors to a service that aggregates, deduplicates, and alerts. Without it, you only hear about the bugs users bother to report — a tiny, biased fraction.
Resources
Primary (free):
- Sentry — Next.js setup · docs
- Vercel — Speed Insights · docs
- web.dev — Measuring real user data · article
Practice
Add Sentry to a deployed project. Trigger a deliberate error in production (a button that throws). Find it in the Sentry dashboard with its stack trace, browser, and the user action that caused it. Done when you can go from "Sentry alert" to "exact line of code" in under a minute.
Outcomes
- Set up error monitoring with source maps so stack traces are readable.
- Capture useful context (user, breadcrumbs) without logging secrets.
- Read field Core Web Vitals from real-user data.
- Decide what's worth an alert vs what's noise.