Observable user promises
Start with five user promises
Replace the examples with your real journeys. A threshold should reflect user harm or an agreed reliability target, not a visually pleasing chart.
The public page is usable
Successful page responses, browser errors and meaningful performance
Investigate whenAvailability or latency deviates enough to block or materially delay use
Context requiredVersion, route, region, device class and dependency status
A user can sign in
Completed authentication journeys by method, not only endpoint status
Investigate whenFailure or loop rate exceeds the normal baseline
Context requiredProvider response, callback domain, cookie behavior and version
A submitted action happens once
Accepted, completed, duplicated and failed mutations
Investigate whenCompletion drops or duplicates appear
Context requiredRequest ID, idempotency key, user-safe category and downstream status
Background work completes
Queue age, scheduled execution and terminal outcome
Investigate whenWork exceeds the user expectation or retry budget
Context requiredJob type, attempt, dependency and owning version
Support can diagnose a report
Correlated user-safe request or event identifier
Investigate whenA customer impact cannot be located within the support target
Context requiredTrace across browser, API, job and vendor without raw sensitive payloads
Instrument the assembled system
A health endpoint can be green while every user is stuck
Process availability says the server can answer one request. It does not show that authentication callbacks, database permissions, email delivery or background jobs fulfill the product promise. Add a small number of synthetic or real outcome signals around the critical journey.
Generated logging often records whole objects because it is convenient. That can leak secrets and customer data while making diagnosis harder. Prefer structured, low-cardinality fields, safe identifiers and explicit error categories.
- Name an owner and action for every alert
- Keep telemetry free of raw secrets and unnecessary content
- Correlate signals across the critical path
- Delete dashboards and alerts that do not change a decision
Decision matrix
Use each signal for the question it answers
Logs, metrics and traces complement one another; none is automatically the source of truth for user success.
| Signal | Best question | Design caution | Operational output |
|---|---|---|---|
| Metric | Is the rate or distribution changing? | High-cardinality labels can create cost and instability | Threshold and trend |
| Log | What categorized event happened? | Raw payloads create privacy and search problems | Structured event with safe context |
| Trace | Where did one request spend time or fail? | Sampling and missing propagation can hide paths | Cross-service timeline |
| Synthetic journey | Can a controlled user complete the promise now? | One path may not represent all users | End-to-end outcome |
| Support signal | What harm are real users reporting? | Volume may be low or delayed | Impact narrative and reproduction |
Applied example
Monitoring failure: thousands of logs, no answer
A checkout flow fails after a payment callback. Each service logs messages, but request identifiers change and the callback log contains the full customer payload.
- The system creates privacy risk without providing reliable correlation.
- A simple payment-completion metric would reveal the user outcome regression.
- A propagated safe identifier would connect the callback to the application action.
- The alert needs an owner and reconciliation procedure, not another dashboard.
Plain answers
Monitoring questions
What should a new product monitor first?+
Its most important user journey, production errors, latency, critical dependencies and the signals required to recover data or service.
Do I need a large observability platform?+
No. Start with the smallest system that produces actionable, retained evidence and can grow with the product’s risk and traffic.
Can analytics replace monitoring?+
Product analytics can show behavior trends, but it may be delayed, sampled or designed for different decisions. Critical operational outcomes need owned reliability signals.