> ## Documentation Index
> Fetch the complete documentation index at: https://docs.testdino.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Test Controls
> Quarantine flaky Playwright tests so their failures stop failing the build, cover one known error, or make a test pass on the first try.
Test Controls sets per-test build rules in TestDino: quarantine a flaky test so its failures stop failing the build, cover only 1 known error, or make a test critical so it must pass on the first try. The TestDino reporter applies the rules when the test run ends.
A quarantined test case keeps running and reporting. Its failures stay in test run results, notifications, analytics, and flaky rates; only the build result changes.
Test Controls requires `@testdino/playwright` 2.8.0 or later. When a quarantined test case fails under an earlier reporter, the test run shows `Quarantine didn't apply to this run. Update the TestDino reporter to use it.` and the build behaves as before.
## Quick Reference
| Action | Effect on the build | Who can use it |
| :- | :- | :- |
| **Quarantine** | Failures of the test stop failing the build until the quarantine ends | Owner, admin, member |
| **Only cover this error** | Only failures matching 1 error stop failing the build | Owner, admin, member |
| **Mark critical** | A pass only on retry fails the build | Owner, admin |
| **Watch** | None. You get a message when the test changes state | Anyone on the project |
| **Assign** | None. The assignee watches the test | Owner, admin, member |
Viewers and billing users can open the **Test Controls** page but not change it.
## Open Test Controls
The **Test Controls** page in the project sidebar has 4 tabs: **Quarantined**, **Candidates** (tests that were flaky in more than 5% of their test runs in the last 30 days and are not quarantined or critical), **Critical**, and **Watching**. The header shows how many quarantine slots are used, for example `3/12 quarantine slots used`.
Each test also has a **Test Controls** button on its test case page in a test run and in the [Test Explorer](/platform/playwright-test-explorer) side panel. The button reads **Quarantined · ends** with the end date when the test is quarantined, or **Critical** when it is critical. Click it to quarantine the test, mark it critical, assign it, or watch it.
## Quarantine a test
A quarantine needs an end date and an assignee.
Click **Test Controls** on the test case page or in the Test Explorer panel, then **Quarantine**. On the **Candidates** tab, click **Quarantine** on a row.
Pick **Ends In**: 7, 14, 30, 60, or 90 days. The project's default duration is preselected. The **Assignee** defaults to the test's assignee, or to you when the test has none. **Note (Optional)** records why the test is quarantined.
Turn on **Only cover this error** to forgive 1 known failure. Any other failure of the test still fails the build. The box holds the first line of the error: from this test run on the test case page, and from the test's most recent failing test run in Test Explorer. Edit it or paste another error.
Only this line is matched. IDs, times, durations, and long numbers can change between test runs; the rest must match exactly. **Only cover this error** is not offered when quarantining several tests at once.
Click **Quarantine**. The test appears on the **Quarantined** tab, and the rule applies from the next test run.
1 quarantine covers the test on every browser and Playwright project it runs on. A test that is already quarantined opens for editing instead, and a critical test cannot be quarantined.
The dialog shows the quarantine limit and disables **Quarantine** when the project is at it, for example `Quarantine limit reached (12 of 12). Release a test, or ask an admin to raise the limit.` A test that has not run in the project recently cannot be quarantined.
## Quarantine several tests at once
Select test cases in [Test Explorer](/platform/playwright-test-explorer) to quarantine them together, for example when an outside service is down. Filter by tag, spec file, or search first, then tick the rows (the header checkbox selects the whole page), and click **Quarantine N tests**.
| Rule | Behavior |
| :- | :- |
| Selection size | Up to 100 tests, from the current page |
| Quarantine limit | The whole selection is quarantined, or none of it if it does not fit |
| Browser variants | 2 variants of the same test count once |
| Skipped tests | Tests already quarantined, marked critical, or not run recently are skipped and listed in the result |
Before you save, the dialog counts the tests it would quarantine. Each test gets its own quarantine and is released on its own.
## How the build result changes
When the test run ends, the reporter checks every failure against the project's rules:
| Situation | Build result |
| :- | :- |
| Every failure is a quarantined test or a matching known error | Passes |
| Any other test case failed | Fails as usual |
| A critical test passed only on retry | Fails |
| An error happened outside a test case (for example in `globalSetup`) | Fails |
| The test run was interrupted or timed out | Unchanged |
| The rules could not be loaded | Unchanged; failures count as usual |
The reporter prints `TestDino Test Controls: fetching rules…` after it authenticates. At the end of the test run it prints the rules it loaded (`TestDino Test Controls: 3 rules (2 quarantined, 0 known errors, 1 critical)`), the quarantined tests that ran (`Quarantined tests in this run: 2 (2 failed, excluded from the build)`), and a verdict. When no quarantined test ran and no critical test passed only on retry, only the rules line appears. The verdict is one of:
| Output | Meaning |
| :- | :- |
| `Build passes: every failure was quarantined` | Only quarantined tests failed |
| `Build fails: 1 failure not quarantined` | A failure no rule covers remains |
| `Build fails: critical test passed only on retry (checkout)` | A critical test needed a retry |
| `Build fails: an error outside a test` | Every test failure was quarantined, but something like `globalSetup` failed |
| `The run ended …, so its status stands` | The test run was interrupted or timed out, so Test Controls did not change it |
| `No failures` | Quarantined tests ran and passed |
Playwright uses the last status a reporter returns. If another reporter in your config sets the test run's status, list TestDino after it.
## What the test run and notifications show
The test run keeps its real status. A test run with a failed test case reads **Failed** even when quarantine passed the build. Its quarantined test cases are tagged **Quarantined**, and the test run notes `2 quarantined failures covered, so they didn't fail the build.`
| Surface | Shows |
| :- | :- |
| Test runs list | The test results cell adds `· 2 quarantined` |
| Slack, PR comments, PR description | The failures count as failed, with `2 quarantined failures covered` |
| GitHub check, commit status, [quality gate](/guides/github-status-checks), webhook `failed` outcome | Follow the build: a test run whose only failures were quarantined passes. The check title adds `· 2 quarantined` |
To find these test runs, filter the test runs list by **Test Controls**: **Changed by Test Controls**, **Had quarantined failures**, or **Critical test passed only on retry**. In a test run's summary, **Filter → Test Controls** narrows it to **Quarantined** or **Critical: passed only on retry** test cases.
## Mark a test critical
A critical test must pass on the first try. If it fails and then passes on a retry, the build fails.
Click **Test Controls** on the test case page, then **Mark critical**. Owners and admins can mark up to 50 critical tests per project. A quarantined test cannot be marked critical until its quarantine is released.
When a critical test passes only on retry:
* The test run stays **Passed**, and the test case is tagged **Critical: passed only on retry**.
* Slack gets a second message right below the test run message, such as `Critical test passed only on retry in run #42`, with each test linked to its page.
* The PR comment opens with a caution box naming the test, and the PR description gets a **Critical test passed only on retry** line.
* The GitHub check title adds `❗ 1 critical passed on retry`, and the quality gate fails.
A critical test that fails outright is an ordinary failure: the build fails as it would for any failure.
## Watch or assign a test
Click **Test Controls**, then **Watch**, to get a message when the test changes state: it starts failing, passes only on retry, or passes again. Click **Stop watching** to end it.
* The first test run after you start watching only records the test's state, so the first message comes with the next change.
* A test sends you at most 1 message every 6 hours. A change inside that window is sent after it, if the test is still in its new state.
* The message is a Slack direct message from the TestDino Slack app when the project's Slack app can reach you, otherwise an email. A Slack workspace connected before Test Controls sends email until the Slack app is reconnected.
To assign a test, click **Assign** in the **Assignee** row. The assignee starts watching the test, so they get the same messages. Test run summaries, PR comments, and Slack channel messages never show the assignee's name.
## When a quarantine ends
Every quarantine ends. The **Released** view on the **Quarantined** tab shows why:
| Why it ended | When |
| :- | :- |
| **Passed enough runs in a row** | The test passed a set number of test runs in a row (default 10) |
| **End date reached** | The end date arrived |
| **Stopped running** | The test did not run in the project's last 14 test runs, for example after a rename |
| **Ticket closed** | The linked Jira or Linear issue was marked done |
| **Released by** a name | Someone released it |
A pass only on retry resets the count to 0, and a test run where the test was skipped does not count. The **Passes in a Row** column shows progress, for example `6 of 10`.
Expand a row to see its **Details**, its **History**, and **Covered failures**: the test runs in the last 90 days whose failure the quarantine kept from failing the build, each linked to its page.
From a row's menu:
* **Extend or edit** changes the end date, assignee, or note.
* **Link ticket** records 1 Jira or Linear issue. When it is marked done, the quarantine is released.
* **Release** ends the quarantine now. The test fails the build again when it fails.
## Configure Test Controls settings
Click **Settings** on the **Test Controls** page. Owners and admins can change these:
| Setting | Range | Default |
| :- | :- | :- |
| **Quarantine Limit (% of Active Tests)** | 0.5% to 50% | 2% |
| **Default Duration** | 7, 14, or 30 days | 14 days |
| **Release After (Passes in a Row)** | 3 to 50 | 10 |
The limit is how many tests can be quarantined at once. At least 1 test is always allowed, and lowering it never releases a test.
## Troubleshooting
The test run used a reporter older than 2.8.0, so quarantined failures counted as usual. Upgrade `@testdino/playwright` to 2.8.0 or later.
The reporter could not fetch the rules in time, so failures counted as usual, and the test run shows `Quarantine didn't apply to this run` with the reason. Check that CI can reach the hosts listed in [Network Endpoints](/security/network-endpoints).
The project holds as many quarantines as its limit allows. Release a test, or ask an owner or admin to raise **Quarantine Limit (% of Active Tests)** in Test Controls settings.
None of the test's browser variants ran in the project's recent test runs, for example because it was renamed or deleted. Quarantine the test under its current name.
Another reporter in your Playwright config set the test run's status after TestDino. Move TestDino last in the `reporter` list.
## Related
Find flaky tests across test runs
Select test cases to quarantine together
Quality gates on pull requests
Install and configure `@testdino/playwright`
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.