What is full-stack monitoring?
Monitoring is knowing what your live app is doing across both halves: client-side errors and performance in the browser, server-side errors and latency, and ideally a way to trace one failing user action through both. It is how you learn about problems before users tell you.
Why it matters
A full-stack bug can originate in either half, and without visibility into both you are debugging blind. Client error tracking catches the JavaScript exceptions users hit; server monitoring catches the API failures and slow queries. Together they turn "a user said it is broken" into a specific, located cause.
What to learn
- Client error tracking (Sentry in the browser)
- Server error tracking and structured logs
- Performance: Core Web Vitals and server latency
- Tracing a request across client and server
- Alerting on error spikes
- Release tracking to tie errors to a deploy
- Respecting user privacy in what you capture
Common pitfall
Monitoring only the server and being blind to client-side errors. A JavaScript exception that breaks the UI for a slice of users may never reach your server logs at all — the request was never made. Add browser error tracking so you see client-side failures, not just server ones.
Resources
Primary (free):
- Sentry — Documentation · docs
- web.dev — Core Web Vitals · docs
- Google SRE — Monitoring · docs
Practice
Add monitoring to both halves: browser error tracking that captures a client-side exception, and server error tracking with structured logs. Tie errors to the current release. Trigger a client error and a server error and confirm both appear. Done when you can see failures from either half.
Outcomes
- Track errors on both the client and server.
- Monitor Core Web Vitals and server latency.
- Tie errors to releases for faster diagnosis.
- See client-side failures, not just server logs.