What it compares against
Each run is compared against the project’s recent baseline: its last few runs, up to 10. Detection needs a baseline to work, so it starts once the project has 5 prior runs. Before that, the tab shows how many runs are still needed.Anomaly types
The tab groups changes into 5 sections.
New failures counts only tests that have run before. A brand-new test failing on its first appearance is a new test, not a regression, so it is left out.
Persistent failures and recovered are collapsed by default: persistent failures are the status quo, and recovered is good news.
What each anomaly shows
Every section lists the affected tests. Click a test to open its details for this run.
The header summarizes the run with clickable chips: new failing, still failing, slower, newly flaky, and recovered. Click a chip to jump to that section.
Severity score
The header shows a severity score from 0 to 100 for the run. New failures, regressions, and shared error clusters raise it; recoveries lower it. A higher score means more, or worse, changes in this run. There are no named tiers, just the number.Shared error clusters
When 3 or more tests fail with the same error, the header shows a cluster badge, such as4-test cluster. It points to the size of the largest group of tests failing for the same reason, so you can fix 1 root cause instead of chasing each failure separately.
The header also breaks failures down by category, with badges like timeout: 8 or assertion: 3.
States you may see
Anomaly detection is per run. It reads run data, so a signed-in user with access to the project can view it, in the app or through a personal access token. CI pipeline keys cannot read it.
Related
Run Summary
Review failed, flaky, and skipped tests by cause
Errors
Group failures by error message within a run
Flaky Tests
Detect and fix flaky tests
Analytics
Track reliability and performance trends over time