# See why a browser test failed before rerunning it

Zerocheck shows the failing step, screenshots, console errors and every attempt. A pass after a supported transient retry stays labeled flaky.

Zerocheck shows the failing step, screenshots, console errors and every attempt. A pass after a supported transient retry stays labeled flaky.

## Who it is for

- Role: Developer on the release rotation
- Company: Teams whose CI failures take time to investigate
- Trigger: A red build needs an explanation before merge

## Why this is underserved

- Rerunning a failure without investigating teaches the team to ignore CI.
- A locator change, an assertion failure and a service error need different responses.
- The original failure should remain visible even if a later attempt passes.

## The workflow

Before: A developer sees a red job, reruns it and loses the context needed to understand why it failed.

After: Open the run, inspect the failing action and expected outcome, and compare the step screenshots. Recovery and flaky labels remain part of the result.

## How Zerocheck handles it

1. Read the failing step and the exact test revision.
2. Check the screenshot, console output and failure type.
3. Fix the product, test data or test description based on the evidence.
4. Use --fail-on-flaky in CI when a flaky blocking test should fail the workflow.

## Good fit when

- A web app and a repeatable user flow
- A test environment, test accounts and an explicit expected outcome

## Frequently asked questions

### Does Zerocheck rerun every failed test?

No. A transient AI-service error can be retried once in the same browser. Assertion failures are not retried.

### Does Zerocheck automatically classify every product bug?

It provides failure details and browser evidence. Engineers still decide the cause and the fix.

---
Canonical: https://tryzerocheck.com/use-cases/flaky-test-triage/
Updated: 2026-09-14