How Monitors Work
Each monitor independently observes your test runs and tracks two states per test: active (problematic behavior detected) or inactive (no problematic behavior). When a monitor transitions to active, it executes its configured action; when it resolves, it undoes that action (restoring health status, or removing the labels it applied). For monitors whose action is Classify test status (referred to below as health classification monitors), the test’s overall status is determined by combining all such monitors, with the most severe status winning:
If a test triggers both a broken monitor and a flaky monitor simultaneously, it shows as Broken. When the broken monitor resolves (e.g., you fix the regression and the failure rate drops), the test transitions to Flaky if a flaky monitor is still active, or to Healthy if no health classification monitors remain active.
A test stays in its detected state until every health classification monitor that flagged it has independently resolved. Monitors configured to apply labels do not contribute to this status calculation — they only add or remove labels.
Disabling or Deleting a Monitor
When you select Disable or Delete from a monitor’s context menu, a confirmation dialog appears first. The dialog describes the concrete effect on affected tests before the change fires. You can re-enable a disabled monitor at any time. When you disable or delete a monitor, it is immediately set to resolved for every test case in the repo. For a health classification monitor, this triggers a status re-evaluation for all affected tests: if the disabled monitor was the only active health classification monitor for a test, that test transitions to healthy; if others are still active, the test remains in the most severe active state. For a labeling monitor, the labels it had applied are removed (subject to its Remove these labels when the monitor resolves setting). For example, if you have a broken failure rate monitor and a flaky pass-on-retry monitor, and you disable the broken monitor, any test that was only flagged by the broken monitor will become healthy. A test flagged by both will transition from broken to flaky (because pass-on-retry is still active). Each affected test case records a Monitor disabled or Monitor deleted event in its Events tab, attributed to the person who performed the action. These events are visible under the Monitors filter category and show the same monitor name and type as the original detection events, making it straightforward to trace why a test transitioned back to healthy.Monitor Types
Trunk groups monitors into two categories based on what they do when they activate:- Health classification monitors determine a test’s overall health status (healthy, flaky, or broken). When one activates, the test’s status changes across the dashboard, CI annotations, and notifications.
- Lifecycle and performance monitors apply labels to tests based on lifecycle events or performance characteristics. They do not affect health status. These monitors appear in a separate section of the monitors page.
Health Classification Monitors
Lifecycle and Performance Monitors
These monitors apply labels based on lifecycle events or performance characteristics. They do not classify tests as flaky or broken, and they do not contribute to the test’s overall health status.
You can run multiple monitors simultaneously. For example, you might use pass-on-retry to catch classic retry-based flakiness while also running failure rate monitors scoped to different branches. A common pattern is to pair a broken-type failure rate monitor (catching consistently failing tests) with a flaky-type failure rate monitor (catching intermittently failing tests). See Failure Rate Monitor: Recommended Configurations for details.
The failure count monitor complements failure rate monitors by reacting to individual failures rather than failure rates. Use it on branches where any failure is a meaningful signal, like
main or merge queue branches.
If you need to manually flag a test that automated monitors haven’t caught, use Flag as Flaky from the test detail page.
Dry-Running with Labels
You can preview how a new health classification monitor would behave by deploying it as a labeling monitor first. Because Apply labels attaches labels without changing health status, you can let the monitor run on live test data, see which tests it activates on, refine the settings, and only flip it to Classify test status once you trust the configuration. The flow is typically:- Create the monitor with Apply labels and a dedicated label (e.g.,
would-be-flaky). - Let the monitor run for a few cycles and observe which tests pick up the label.
- Refine the settings until the labeled set matches what you want classified.
- Switch the monitor’s action to Classify test status.
Branch-Aware Detection
Tests often behave differently depending on where they run. Failures onmain are usually unexpected and signal flakiness. Failures on PR branches may be expected during active development. Merge queue failures are suspicious because the code has already passed PR checks.
Rather than applying a single set of branch rules automatically, Trunk gives you control over how detection treats different branches through branch scoping on failure rate monitors. You can create separate monitors with different thresholds and windows for your stable branch, PR branches, and merge queue branches. See Failure Rate Monitor: Recommended configurations for specific guidance.
Pass-on-retry detection is branch-agnostic. It flags any test that fails and passes on the same commit, regardless of which branch the test ran on.
Muting Monitors
You can temporarily mute a monitor for a specific test case. A muted monitor continues to run and record detections, but it won’t contribute to the test’s flaky status until the mute expires. This is useful when you know a test is flaky but want to suppress the signal temporarily, for example while a fix is in progress or during a known infrastructure issue. Unlike Flag as Flaky, which is a persistent user override, muting preserves the detection history and automatically re-enables itself after the mute period.How Muting Works
You can mute a monitor from the test case view in the Trunk app. When muting, you choose a duration:
While muted, the monitor is excluded from the test’s status calculation. If the muted monitor was the only active health classification monitor, the test transitions from flaky to healthy for the duration of the mute. When the mute expires, the monitor is automatically included in the next status evaluation. If it’s still active, the test will be flagged again.
You can also unmute a monitor early from the test case view.
You can only mute a monitor that has already detected flaky behavior for a
test. If a monitor has never been active for a test, the mute option is
disabled.