# Analytics Dashboards: Panels and Views

> Work the Analytics dashboard: project overview, execution and performance summaries, endpoint analytics, environment comparison, and trends.

Source: https://totalshiftleft.ai/help-center/product-documentation/analytics-dashboards

## Overview

The Analytics dashboard is where execution history becomes something you can act on. It's project-scoped — **Select a Project** first — and bounded by a time range.

Requires a **Pro**, **Trial**, or **Enterprise** plan. For what Analytics is and how it differs from Reporting, start with [Understanding analytics](/help-center/product-documentation/understanding-analytics).

## Setting the frame

Two controls determine everything else on the page:

- **Project** — which project's history you're looking at.
- **Time range** — **Last 7 days**, **Last 30 days**, **Last 90 days**, or **Last year**.

Get the range wrong and the dashboard will look fine while hiding exactly what you're hunting for. A quick guide:

| You're asking | Use |
|---------------|-----|
| "Did last night's change break something?" | Last 7 days |
| "Is this sprint better than the last?" | Last 30 days |
| "Are we actually improving?" | Last 90 days |
| "What does the long-run trend look like?" | Last year |

## Project Overview

The headline numbers for the project in range:

| Metric | Read it as |
|--------|------------|
| **Total Tests** | Volume — how much ran. |
| **Success Rate** | The proportion passing. |
| **Coverage %** | How much of the API surface is exercised. |
| **Failed Tests** | Absolute failure count. |
| **Avg Response Time** | Typical latency. |

Read **Success Rate** and **Coverage %** together, always. High success on low coverage means you're reliably testing a small slice of your API — reassuring and not very informative. The healthy direction is coverage climbing while success rate stays roughly flat.

## Execution Summary and Test Status Breakdown

Run outcomes over the range, split across **Passed**, **Failed**, **Error**, and **Not run**.

Watch the **Error** band specifically. Errors mean requests never completed, so a rising Error band is an environment or connectivity story, not an API quality story. Teams routinely spend days "fixing failing tests" that were never failing — they were erroring, and the API was fine.

## Performance Summary and Response Time Distribution

**Avg Response Time** gives you the trend line. **Response Time Distribution** gives you the shape, and the shape is where the information is.

An average that holds steady while the distribution's tail stretches means most requests are unchanged and some are getting much worse. That's the profile of a problem your users hit and your average doesn't show — a slow query on a growing table, say.

## Endpoint Analytics

Health per endpoint. This is how you find the one operation dragging a project's numbers down, rather than treating the whole API as uniformly healthy or unhealthy.

Pair it with **Top Failing Tests**: an endpoint with a high failure rate and one test failing repeatedly is a different problem from an endpoint where many different tests fail intermittently. The first is likely a real bug in one behaviour; the second smells like the endpoint or its environment being unstable.

## Environment Comparison

The same tests, across environments. This settles the most common argument in triage — *is it broken, or is it just staging?*

- **Fails everywhere** — it's the contract or the code. Real.
- **Fails in one environment only** — it's that environment: config, data, or connectivity.

Checking this before filing a bug saves a round trip almost every time.

## Trends Analysis

Movement over the range. Useful for the questions a single run can't answer: is the suite getting slower, is coverage actually growing, is the failure rate trending down after a fix.

Trends only mean something with enough history behind them — on **Last 7 days** with two runs, a "trend" is a line between two dots.

## Sharing what you find

Dashboards can be shared and embedded — see [Sharing and embedding dashboards](/help-center/product-documentation/sharing-and-embedding-dashboards). To tailor a view to a specific audience, see [Custom dashboard personas](/help-center/product-documentation/custom-dashboard-personas), and for regular delivery see [Scheduled reports and alerts](/help-center/product-documentation/scheduled-reports-and-alerts).

## Troubleshooting

- **"No analytics data available"** — no runs in range for this project. Widen the range.
- **"No endpoint analytics data available"** — no per-endpoint data in the selected range.
- **"No environment comparison data available"** — the tests have only run in one environment; there's nothing to compare.
- **The dashboard looks healthy but you know something is broken** — check the time range first, then whether the failure is in this project.
- **Coverage % is lower than expected** — coverage reflects tests that exist, not endpoints that were imported. See the coverage verdict on [Test case](/help-center/product-documentation/test-case).
- **Avg Response Time is flat but users report slowness** — read **Response Time Distribution**; the average is hiding the tail.

## Related articles

- [Understanding analytics](/help-center/product-documentation/understanding-analytics)
- [Project analytics](/help-center/product-documentation/project-analytics)
- [Custom dashboard personas](/help-center/product-documentation/custom-dashboard-personas)
- [Sharing and embedding dashboards](/help-center/product-documentation/sharing-and-embedding-dashboards)
- [Scheduled reports and alerts](/help-center/product-documentation/scheduled-reports-and-alerts)