Observability is for User Happiness
summary
Makes the concrete claim that observability must measure user happiness not server nines and shows how Honeycomb instruments a React web app with tracing derived from events and resource timing and uses OpenTelemetry style spans and Webpack Lighthouse data to act on problems. Surprising specifics include hitting the browser 6 concurrent requests limit and a median window size of 85% driving UI layout changes. Teams build in tracing, batch spans to avoid slowdown, set performance budgets and SLOs and report that SLO setup takes months but yields business buy in.
AI-written summary · about
chapters (8)
- 0:00Introduction and context
- 8:36Data models in practice
- 13:20Tracing and instrumentation
- 17:50Analysis and behavioral insights
- 21:42Budgets versus objectives
- 27:26Practical optimization stories
- 34:02Using data for product design
- 40:06Q&A session
related talks
44mObservability: Superpowers for Developers
35mObservability: Building Confidence & Answering the What, Where, How
31mObservability for Developers: How to Get There
50mObservability and the Development Process
17mUnlocking Observability with React & Node.js
23mA peek into observability from a tester's lens
17mObservability in frontend: React Open Telemetry
29mObservability; a gentle introduction