> ## Documentation Index > Fetch the complete documentation index at: https://docs.peepsai.com/llms.txt > Use this file to discover all available pages before exploring further. # Analytics > See how healthy a project's tests are over a period or in one release: pass rate, what newly failed, became flaky or got fixed, which folders fail most, and the issues behind the failures. The **Analytics** page answers one question: how healthy are these tests, in these runs? You pick the runs, the tests, and what to break them down by, and the page shows the pass rate, what changed since the period before, where the failures are, and why they failed. Open it from **Analytics** in the sidebar, under **Health**. It shows one project at a time. Everyone in your organization can see it, whatever their role. ## Pick what you look at Three controls sit at the top of the page. Each choice is kept in the page's link, so you can share exactly the view you see. | Control | Choices | | - | - | | **Which runs** | **Period**: the runs in a window of time. **Release**: one release's results. See [Period or release](#period-or-release). | | **Which tests** | **All test cases**, or one folder, team, tag or selection. A folder includes its subfolders. | | **Break down by** | **Folder**, your configurations, **Release**, **Environment**, **Cause** or **Team**. | In Release mode a fourth control, **Compare with**, picks the release to compare with. See [Release mode](#release-mode). A line under the controls says what the numbers count. ### Which tests * **A folder or a tag** holds the test cases in it today. A test case moved to another folder yesterday counts under its new folder, with all its runs, including the ones from before the move. * **A team** holds the test cases it owns today: a test case's own team, or else the team of its folder or the nearest folder above it. The list shows every team in your organization, so a team that owns nothing in this project shows no test cases. * **A selection** counts differently in each mode. In Period mode it counts only the runs it launched: a test case run directly, or by another selection, is left out. In Release mode it holds the test cases in the selection today. * **Archived test cases** are left out, as on the **Test cases** page. ### Break down by | Breakdown | What each row is | | - | - | | **Folder** | A top-level folder. When **Which tests** is a folder, its direct subfolders, with the folder's own test cases under the folder itself. Test cases in no folder are under **No folder**. | | Configuration | One configuration your results report. The option carries your project's name for it, such as **Camera**. Runs Peeps ran with no configuration are under **Peeps**, and results a person recorded under **Manual**. | | **Release** | One release. Period mode only, since Release mode shows one release. | | **Environment** | The environment the runs ran in. | | **Cause** | The cause of the failures. Only failures are split. | | **Team** | The team that owns each test case today. Every result counts, not only app bugs. | **Camera model** is listed but not available yet: runs don't record a camera model. ## Period or release The two modes count different things. | | Period | Release | | - | - | - | | **What counts** | Every run in the window, after retries | Each test's latest result per configuration in the release | | **Matches** | Each test case's health on its own page | The release report's header and the **Releases** list | | **Compared with** | The period just before, of the same length | The release the release report compares with, or one you pick | | **Newly failing and fixed** | Test cases, against the period before | Results, as the release report counts them against the release compared with | | **Flaky tests** | Yes | No: a release has one latest result per test and configuration, with no retries | ## Period mode Pick a window: **7 days**, **30 days**, **3 months**, **1 year**, or **Custom range**. A custom range is up to 366 days and ends today or earlier. Days start and end at midnight in your time zone, so a teammate in another time zone can see a run near midnight on a different day. ### What counts * **A run is an attempt and its retries.** Its result is the result of its last attempt. Its first try is its first attempt. * **Pass rate** is passed runs divided by passed and failed runs. A timeout is a failure. * **Environment errors, cancelled and skipped runs** are shown but not counted. They say nothing about whether the test passes. * **Every run counts**, whoever started it: Peeps, your CI, a person recording a manual test, or results you uploaded. ### The summary cards | Card | What it shows | | - | - | | **Pass rate** | The pass rate after retries, and its change in points against the period before. Under it, **First try** is the pass rate if no retry had run, with its own change. | | **Test cases with a failure** | How many of the test cases that ran had a run fail after retries, such as `4 of 120`. Under it: the runs counted, the runs that failed after retries, and the runs not counted. | | **Newly failing** | Test cases that failed this period and had no failure in the period before. | | **Newly flaky** | Test cases that are flaky this period and weren't in the period before. Under it: how many runs passed only on a retry. | | **Fixed** | Test cases that failed in the period before and have no failure this period. | ### Newly failing, newly flaky and fixed These three cards compare test cases, not runs, and only test cases that have a counted run in both periods. A test added this period that fails from its first run isn't newly failing, and one that stopped running isn't fixed. When no test case ran in both periods, the three cards show **—** and **No comparable results**. A test case is **flaky** in a period when either of these happened: * **A retry cleared a test failure.** A run failed and then passed on a retry. A retry that clears an environment error doesn't count. * **Its results flipped twice.** Its results switch between passed and failed at least twice on the same configuration, such as passed, failed, passed. For runs from your CI, the same Playwright project counts as the same configuration. For runs Peeps ran, the same environment does. Manual results record no environment, so they're read on their own, apart from Peeps runs. Flipping twice is what keeps a real change out: a test that passes and then keeps failing is newly failing, and one that fails and then keeps passing is fixed. A test that always fails on one camera and always passes on another is failing, not flaky, and so is one that always fails on staging and always passes on production. | Card | A test case counts when it ran in both periods, and | | - | - | | **Newly failing** | It had no failed run before, has one now, and isn't flaky now. | | **Newly flaky** | It's flaky now and wasn't before. | | **Fixed** | It had a failed run before, has none now, and isn't flaky now. | A test case flaky now is neither newly failing nor fixed, so no test case counts in two cards. ## The breakdown The section under the cards splits the view by your **Break down by** choice. Each row shows its pass rate, how many runs (or, in Release mode, results) it counted, how many failed, its **Cases with a failure**, and its **Change** against the period or release compared with. In Period mode, except by cause, a row also shows its **Flaky cases** and a **Trend**: one pass rate per day or week of the period. ### Worst first Broken down by **Folder** or **Team**, the rows come worst first: 1. The most test cases with a failure. 2. Then the lowest pass rate. 3. Then the most flaky test cases. 4. Then the name. **No folder** and **No team** are ranked like any other row. Other breakdowns keep their own order. ### Open a folder or team from its row Click a folder's or a team's row to open it: **Which tests** changes to that folder or team, and the view keeps your runs, your period or release, and your breakdown. The numbers you then see are the row's. **Back** returns you to the list, and you can share the link or open it in a new tab. A team's row opens only when **Which tests** is **All test cases**. Under a folder, tag or selection, a team's row counts only that part of the team's test cases. These rows don't open: * The row for the folder's own test cases, since that folder is the view you're looking at. * **No folder** and **No team**. * Folder rows under a tag, a selection or a team, since the folder holds more test cases than the row counts. When a view holds too many runs to count, the page says so and suggests a shorter window or a folder, with links to the folders one level down. ## Why they failed **Why they failed** lists the failures after retries by cause, largest first, and who each cause goes to: | Cause | Goes to | | - | - | | App bug | The team that owns the test case, from **App bugs by owning team** | | Test script or test data | **Test maintainers** | | Environment | **Platform** | A failure Peeps hasn't analyzed is listed as **Not analyzed**. A failure a person recorded in a manual test run is **Failed (manual)**. **App bugs by owning team** counts the app bugs by the team that owns each test case today, with how many runs failed, how many test cases they belong to, and how many of those analyses were low confidence. Test cases with no team are under **No team**. ## The Issues panel The **Issues** panel, beside **Why they failed**, lists the view's failures as issues: failure groups from Peeps' analysis, each with its issue in your tracker and how many failures it holds. Above the list it counts the issues by where they stand in your tracker, such as open, done, or not tracked. * **In Period mode**, an issue is runs that ended failed with similar failure text, so a failure a retry cleared isn't an issue. An issue opens its latest failed run, where you can create a tracker issue. * **In Release mode**, an issue is one of the release report's failure groups. An issue whose tracker issue is done but that failed again reads **done, failed since**; one with no failure since reads **done, needs retest**. An issue opens its page in the release. The panel lists every issue in the view; it doesn't follow **Break down by**. You create or link a tracker issue on the page an issue opens, not in the panel. ## The test cases table **Test cases, least stable first** lists each test case: the lowest pass rate first, then the most failed, then the most saved by a retry. Its last column is the test case's issue in your tracker, with **+N** when it has more, or **Not tracked** when a failing test case has none. A test case that didn't fail shows **—**. In Release mode a **Fails on** column names the configurations a test case fails on. ## Release mode Release mode shows one release, counted the way its release report counts it: each test's latest result per configuration. So the page, the release report and the **Releases** list show one pass rate for a release. The pass rate is a whole percent. * **Errors count as failures.** Skipped, blocked, retest and N/A results are shown but not counted. * **No first try and no flaky tests.** A latest result has no retries behind it. * **The release** is the one you pick. With none picked, the page opens on the newest release that has results. A release created with no results yet is listed as **No results yet**. * **Compare with** starts on **As the release report does**: the nearest earlier release that shares a result with this one. Pick another release to compare with it instead. When the two releases share no result, no change is shown. * **Which tests** picks within the release's latest results. Results not linked to a test case are left out of every count, and the **Not linked to a test case** card counts them when **Which tests** is **All test cases**. The summary cards are **Pass rate**, **Results counted**, **Test cases with a failure**, **Newly failing**, **Fixed** and **Not linked to a test case**. **Open the release report** links to the release's report, and the report's **Open in Analytics** brings you back, keeping the release compared with. ### Newly failing and fixed in a release **Newly failing** and **Fixed** are the release report's own comparison with the release compared with, so they match the report's **Compared with** card and the **Releases** list's **New / fixed** column. * **They count results, not test cases.** A test case newly failing on two configurations counts 2. * **Newly failing** passed in the release compared with and fails now. An error counts as a failure. * **Fixed** failed in the release compared with and passes now. A test that stopped running isn't fixed. * **When nothing is compared**, because there's no earlier release or the two share no result, both cards show **—** and **No comparable results**. A **0** means the releases share results and none changed. * **With a folder, tag, team or selection picked**, they count the report's newly failing and fixed results within those test cases. The release report's own card always counts the whole release. There's no **Newly flaky** card in Release mode: a latest result has no retries behind it. ## One test run From a test run's page, **Compare with the previous run** opens that run on the Analytics page on its own. It compares the run with the newest earlier finished run of the same selection in the same environment, test case by test case: **Newly failing**, **Still failing**, **Fixed**, and **Saved by a retry**. When there's nothing to compare with, such as a run not launched from a selection, the page says why and still shows the run's numbers. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.