Worked Answer: Frontend Observability
Prompt
Design frontend observability for a SaaS app with multiple routes, experiments, releases, tenants, and third-party scripts.
1. Clarify
Ask:
- Which routes and workflows are business-critical?
- What privacy constraints apply?
- How are releases, feature flags, and experiments represented?
- Which backend traces need frontend correlation?
- Who owns alerts and incident response?
- What third-party scripts can affect user experience?
2. Signal taxonomy
| Signal | Purpose |
|---|---|
| Web Vitals | user-perceived loading, responsiveness, stability |
| route transitions | navigation health and route-level failure |
| JS errors | client defects and release regressions |
| API errors | frontend/backend contract health |
| resource failures | CDN, image, script, font failures |
| user workflow events | task completion and abandonment |
| feature flag/experiment context | release and variant attribution |
| third-party script cost | vendor performance and reliability risk |
| accessibility signals | detected defects and user-impacting failures |
3. Architecture
4. Event schema
Minimum fields:
- event name
- schema version
- route id
- release id
- build id
- feature flag snapshot
- experiment assignment
- device class
- network class where available
- tenant class, not raw tenant name
- trace/request id
- consent/purpose label
Avoid:
- raw user input
- full URLs with sensitive query params
- emails, names, phone numbers
- access tokens
- free-form object dumps
5. Dashboards
| Dashboard | Answers |
|---|---|
| route health | which routes are failing or slow? |
| release health | did the latest release regress? |
| experiment health | did a variant affect performance/errors/conversion? |
| third-party health | which scripts add cost or fail? |
| critical journey | where do users abandon? |
| security/privacy telemetry | are events rejected, CSP violated, or scripts drifting? |
6. Alerting
Alert only when action is clear:
- critical route error spike by release
- p75 INP regression on critical interaction
- LCP regression on acquisition route
- export workflow failure spike
- CSP violation spike after release
- telemetry sensitive-field rejection spike
- third-party script cost exceeds budget
Every alert needs owner, runbook, severity, and rollback path.
7. Privacy model
Use first-party collection, typed schemas, and destination routing. Observability should be privacy-aware by design:
- minimize before redaction
- reject sensitive fields at SDK boundary
- separate operational telemetry from growth analytics
- store trace ids instead of raw account identifiers
- apply retention rules by purpose
8. Tradeoffs
| Decision | Tradeoff |
|---|---|
| sample high-volume events | lower cost, less complete detail |
| first-party collector | more platform work, better control |
| route-level dashboards | more taxonomy work, better ownership |
| strict schema validation | dropped events, better privacy and data quality |
Strong close
Frontend observability is successful when a regression can be answered quickly: what route, what release, what cohort, what user journey, what backend trace, what owner, and what rollback. It is not successful just because events are flowing.