Skip to content

[DNM Demo ] :: [TRUNK-17702] Document indefinite monitor muting for flaky tests #463

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
samgutentag wants to merge 1 commit into from
Closed

[DNM Demo ] :: [TRUNK-17702] Document indefinite monitor muting for flaky tests #463

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 32 additions & 3 deletions flaky-tests/managing-detected-flaky-tests.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,36 @@ It is important to keep the team informed on all status changes for flaky tests
* Trunk's built-in templates help you get started and test the connection.
* You can then customize the transformation to update the message format and content, including @-mentioning test owners so they can follow up right away.

### Step 3: Start quarantining manually
### Step 3: Mute monitors

If a flaky test has a fix in progress or is affected by a known infrastructure issue, you can mute the monitor that flagged it. A muted monitor continues to run and record detections, but it won't contribute to the test's flaky status until the mute expires or is manually removed.

To mute a monitor:

1. Navigate to the test case detail page in the Trunk app.
2. Find the monitor that flagged the test.
3. Click **Mute** and select a duration.

| Duration | Description |
|---|---|
Copy link
Contributor

@claude claude bot Mar 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The table descriptions are inconsistent in depth. The 1 hour row gives a meaningful reason ("transient issues"), while 24 hours, 7 days, and 30 days just restate the duration in different units — readers can already infer "7 days = a week" from the Duration column. Consider making all descriptions equally informative, e.g.:

Duration Description
1 hour Suppress briefly for transient or one-off issues
4 hours Short-term suppression for issues expected to resolve in a few hours
24 hours Suppress overnight or across a full workday
7 days Suppress while waiting for a fix in the current sprint
30 days Suppress for a longer-running or deprioritized fix
Forever Mute indefinitely until manually unmuted

| 1 hour | Quick suppression for transient issues |
| 4 hours | Short-term suppression |
| 24 hours | Suppress for a full day |
| 7 days | Suppress for a week |
| 30 days | Suppress for a month |
| Forever | Mute indefinitely until manually unmuted |

The **Forever** option mutes the monitor with no expiration. The monitor stays muted until you explicitly unmute it from the test case detail page. This is useful when a test is a known flake that your team has accepted, or when a fix is planned but not yet scheduled.

For timed durations, the monitor automatically unmutes when the period expires. If the monitor is still detecting flaky behavior at that point, the test will be flagged as flaky again.

You can unmute a monitor at any time from the test case detail page, regardless of the selected duration.

{% hint style="info" %}
Muting suppresses the monitor's contribution to the test's status. If the muted monitor was the only active monitor for a test, the test transitions from flaky to healthy for the duration of the mute.
Copy link
Contributor

@claude claude bot Mar 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"for the duration of the mute" is slightly ambiguous when the Forever option is selected (there is no duration). Consider rewording to "while the monitor is muted" to cover both timed and indefinite cases:

Suggested change
Muting suppresses the monitor's contribution to the test's status. If the muted monitor was the only active monitor for a test, the test transitions from flaky to healthy for the duration of the mute.
Muting suppresses the monitor's contribution to the test's status. If the muted monitor was the only active monitor for a test, the test transitions from flaky to healthy while the monitor is muted.

{% endhint %}

### Step 4: Start quarantining manually

Flaky tests slow down CI and have a high negative impact on merge queue throughput. You can minimize or eliminate this CI slowdown by [quarantining](quarantining.md) flaky tests at runtime.

Expand All @@ -44,7 +73,7 @@ Flaky tests slow down CI and have a high negative impact on merge queue throughp

After quarantining a test, Trunk will ignore the test result (pass/fail) on CI runs, preventing this flaky test from failing CI.

### Step 4: Automation
### Step 5: Automation

Trunk has [webhooks](webhooks/) and [Flaky Tests APIs](flaky-tests.md) that can be used to build custom workflows around ticket creation, linking existing tickets to Trunk, sending notifications, and dealing with quarantined tests.

Expand All @@ -56,7 +85,7 @@ There is also built-in automation support that handles tasks such as assigning f

You can customize how flaky and quarantined tests are handled to suit your team and organization best.

### Step 5: Review existing flakes
### Step 6: Review existing flakes

It is important to track and triage existing flaky tests over time. Trunk collects historical failure logs and stack traces for flaky tests, providing developers as much information as possible for debugging high-impact flaky tests.

Expand Down
Loading