Analytics
Analytics answers the question that raw CI logs cannot: is this API behavior getting better, worse, or noisier over time?
In the current webapp, analytics is not one single top-level module. The signal is split across the Home dashboard, Target tabs, Reports, and Performance:
| Surface | What it reads |
|---|---|
| Home Dashboard | Recent functional run pass rate, active alerts, and recent org activity. |
| Target Overview / Runs / Tests / Endpoints | Target-local health, failures, test history, and endpoint behavior. |
| Target Metrics | Custom functional metrics emitted by ctx.metric(). |
| Reports | Generated health digests for an org or project scope. |
| Performance | Load-run latency, throughput, error rate, thresholds, and capacity for one Target. |
The Signals Most Teams Use
- Pass rate trend to spot regressions
- Flaky tests to find unstable tests
- Top failing tests to prioritize cleanup work
- Failure distribution to separate assertion bugs from timeout or network noise
- Endpoint latency to find performance regressions from trace data
- Test duration trend to catch tests that are getting slower
These are functional-suite trends, built from uploaded test and contract runs. They are distinct from the load-test Performance surface: a test duration trend tracks how long a test takes; load-test latency, throughput, and capacity live under Performance.
Custom metrics
If your tests emit custom metrics through ctx.metric(), Cloud shows them on
the Target’s Metrics tab.
Good uses of analytics
- deciding which failures matter most
- proving a flaky suite is actually improving
- detecting a slow endpoint before it becomes a production issue
Next
- Dashboard
- Performance — load-run latency, throughput, and capacity
- Benchmarks — cross-source load comparison
- Notifications
Last updated on