Skip to main content
Momentic starts with the least invasive response and escalates only when needed.
1

Locator auto-healing

Re-resolve a stale target or wait for the page to settle. The current step continues without editing the test.
2

Transient recovery

Failure recovery generates temporary steps to clear an obstruction, then retries the failed step. The test still does not change.
3

Permanent healing

Classification and triage explain the failure, decide whether it is healable, and permanently repair the test when possible.
4

Quarantine

Take an unresolved flaky test out of the run so it cannot block CI, with the option to keep running it for data.
Not every failure reaches every layer. Real product regressions and infrastructure failures remain failures; quarantine is containment, not a repair.

​
Locator auto-healing

When a cached target no longer matches the page, the locator agent finds the element again from the step’s description. Smart waiting also waits for navigation, requests, and page changes to settle before the action runs. The resolution applies to the current run and never edits the test. After an eligible successful run, Momentic can save it to the step cache for fast replay.
Locator auto-healing diff

A locator re-resolved during a run

If the target is correct but a temporary condition still blocks the flow, the next layer is transient recovery.

​
Transient recovery

Failure recovery is in beta and may change.
During eligible CI runs, failure recovery can generate temporary steps to clear a cookie banner, wait out a transition, or handle another transient obstruction. It then retries the failed preset step. Generated steps apply only to that run and never edit the test. Enable it in momentic.config.yaml:
momentic.config.yaml
When in-flow classification is enabled, the classifier investigates the failure first. Only failures mapped to heal and judged recoverable trigger a recovery attempt. Without classification, a built-in recovery planner makes that decision. Recovery does not run in the editor and stops after three recoveries in one run. Only failed preset steps are eligible, including preset steps inside modules; module containers and AI action steps are not. It does not hide product regressions, configuration errors, network outages, 5xx responses, CAPTCHAs, or browser crashes. See AI configuration for the full reference. Frequent recovery is a flakiness signal. Use permanent healing to find and fix the cause.

​
Permanent healing

Classification and triage form one post-run maintenance loop:
  1. Classify examines run artifacts, repository changes, prior runs, and any service logs in the results directory. It assigns a category, reasoning, and the configured heal, warn, or fail action.
  2. Triage, when it runs, groups related failures, repairs the affected tests, and verifies each change. Recovered runs are included when triage can replace the temporary recovery with a test change.
  3. Deliver opens a pull request or draft, commits the repair, prints a patch, or leaves the changes on disk according to your Triage settings.
Run tests into a results directory, then triage failures from that directory:
When a heal opens a pull request, two optional toggles in Triage settings control who is added to it: Assign original commit authors to pull requests assigns the original authors of the healed tests as assignees, and Request original commit authors as reviewers requests those same authors as reviewers. Both draw on the same participants (the source pull request’s assignees plus the commit authors and co-authors that GitHub resolves for the change) and default to off. Classification behavior is configured in ai.classification. Category actions and project-specific classification guidance live in Classification settings. You can override an incorrect category from the run viewer. To keep CI passing while a heal is pending, in-flow classification can return a successful exit code for failures routed to heal or warn while failures routed to fail still block the build. See Let the verdict gate CI. For CI, make sure triage runs even when the test step fails. Each repair attempt starts a browser, so if browsers run locally, size the runner for up to one browser per --parallel worker (one by default):
.github/workflows/momentic.yml
The complete auto-maintenance workflow includes authentication, permissions, checkout, and browser setup. See the GitHub Actions guide or another CI integration for runner setup. The momentic ai reference covers alternative run selectors, queue filters, parallelism, delivery overrides, and exit codes. If a recurring flake cannot yet be repaired, contain it with quarantine.

​
Quarantine

Quarantine takes a flaky test out of the run so its failures cannot fail the build; quarantined tests are skipped by default. Pass --skip-quarantined false to keep running them without affecting pipeline status — the run remains visible in the dashboard as a quarantined failure, so you keep the evidence needed to fix it.
You can also quarantine from the run viewer or the dashboard’s Quarantine page. Quarantine rules can act automatically based on pass rate, failure count, flake rate, or transient recovery usage. See the momentic quarantine reference for commands and rule options. Quarantine should be temporary. Continue with debugging flaky tests, then remove the quarantine when the test is stable.