Analyzing usage and application performance
Analyze metrics by using collected telemetry
Usage tells you what to work on
| Question | Telemetry |
|---|---|
| Which features are used? | Custom events, page views |
| Where do users abandon? | Funnels, session flow |
| Who is affected by this error? | Exception telemetry with user context |
Usage data is what makes a hypothesis testable — it is the loop that closes feature flags and A/B testing back into a decision. Without it, "we shipped it" is the end of the story rather than the middle.
Performance analysis
Work from the user inward:
- Which operations are slow? Request duration by name, at p95 and p99.
- What are they waiting on? Dependency telemetry — database, HTTP, queue.
- Where inside the code? Traces and profiling.
Skipping to step 3 is the common mistake: it produces a detailed answer about something that was never the problem.
Aggregates hide people
An average conceals the tail, and a healthy overall error rate conceals a single customer failing every request. Segment — by operation, region, client version, tenant — because one broken tenant inside a 0.1% global error rate is invisible in the aggregate and total for that customer.
Correlate with deployments
Release annotations put deployments on the chart. Most performance regressions have a deployment immediately before them, and seeing the two together is the fastest available diagnosis.
Primary sources