---
title: Failed Test Retry Count
slug: suite-documentation/failed-test-retry-count
docTags: 
createdAt: 2026-04-29T08:37:37.581Z
---

## Overview

**Failed Test Retry Count** defines how many times a failed scenario will be automatically re-executed within the same test run. Its purpose is to improve result reliability by reducing false negatives caused by transient or non-deterministic issues such as network instability, temporary environment problems, third-party service delays, or UI interaction errors like *element not found* or *element not clickable. *In such cases, a simple re-run can stabilize the outcome without masking consistent failures.

It is designed to improve **result reliability**, not to mask consistent or deterministic failures.

## Scope and Behavior

- Configured at **Plan level** and applies to all scenarios within that plan 
- Only scenarios ending with **Error** or **Failure** status are eligible for retry 
- Each retry is treated as a **new execution attempt** of the same scenario 
- Retries are executed within the **same test run lifecycle** 
- If any retry attempt succeeds, the scenario is marked as **Passed** in the final result 

## Retry Trigger Conditions

Retries are triggered only for the following statuses:

- **Error** 
- **Failure** 

The following statuses do **not** trigger a retry:

- Passed / Success 
- Skipped 
- Aborted or other non-executed states 

## Execution Logic

- Scenario runs once (initial execution) 
- If result is: 
  - **Error** or **Failure** → Retry is triggered (up to defined count) 
  - Any other status → No retry is performed 
- Retry execution continues until: 
  - A retry attempt **passes**, or 
  - The defined retry count is exhausted 
- If any retry attempt passes → Final result is **Passed** 
- If all attempts (initial + retries) end with Error/Failure → Final result is **Failed** 

Example:

- Retry Count = 2 
- Execution flow: 
  - Initial run → Failure 
  - Retry 1 → Error 
  - Retry 2 → Passed 
- Final result → **Passed** 

## Configuration

Retry count is defined during **Plan editing in Advanced Settings**

- Accepts numeric values (0, 1, 2, …)
- Default value: **0** (retry disabled)

## Reporting and Results

- Each retry attempt is recorded as part of execution history 
- Final scenario status reflects the **last successful attempt**, if any 
- Reports may include visibility into: 
  - Initial failure 
  - Retry attempts 
  - Final outcome 

This helps identify **flaky or unstable scenarios**.

## Best Practices

- Use retry for **intermittent issues**, not consistent failures 
- Keep retry count low (typically **1 or 2**) 
- Investigate scenarios that frequently pass only after retries 
- Combine with proper logging to understand root causes 

## Key Considerations

- Retry increases **total execution time** 
- Overusing retry may hide real defects 
- Should be used as a **stability support mechanism**, not a primary solution