Observability in Frontend
On this page
Observability Goals
- Detect user impact quickly.
- Explain failures with context: route, release, device, network.
- Reduce mean time to resolution with actionable signals.
Core Signals
- Errors: uncaught exceptions, unhandled promise rejections, error boundary events.
- Performance: LCP, CLS, INP, TTFB, hydration time, long tasks.
- Availability: API error rates by endpoint and route.
- UX: rage clicks, broken navigation, form abandon rate where relevant.
Event Correlation
- Attach correlation ids: session id, request id, trace id if available.
- Attach release metadata: build version, commit hash, deployment region.
- Ensure privacy controls: avoid PII and secrets in telemetry payloads.
Instrument Error Boundaries
- Report boundary caught errors with route and feature identifiers.
- Record recovery actions: retry clicks and navigation away.
Performance Budgets
- Set budgets for bundle size, LCP, and hydration time.
- Fail builds or warn on regressions.
- Track real user metrics, not only lab metrics.
Operational Dashboards
- Error rate by release and route.
- Core web vitals by device class and network type.
- API latency and 429 rate limiting events.
- Auth failures and redirect loop detection.
Failure Modes
- No release tagging, cannot correlate spikes to a deploy.
- PII leaks into logs, creating compliance incidents.
- Over sampling hides low frequency but high impact bugs.
- Client logs are too noisy and lack actionable context.
Incident Playbook
- Step 1: Identify impacted routes and release versions.
- Step 2: Check if failure is client crash, API error, or auth loop.
- Step 3: Correlate with backend traces using request ids.
- Step 4: Roll back or gate the feature, then ship a fix.
- Step 5: Add regression tests and telemetry for the root cause.
Production Checklist
- Errors, performance, and API failures are instrumented.
- Telemetry includes route and release metadata.
- No PII or secrets in client logs.
- Budgets exist and regressions are visible in CI.