Unstable stories and quarantine

Keep noisy stories visible while protecting the rest of your review workflow.

What Unstable means#

A changed story may be captured again. If the second image differs from the first and matches the accepted baseline, the original change did not reproduce in that check. Framecheck groups it as Unstable, labelled not blocking.

That is evidence of an intermittent result, not proof that the first change could never be real. A story whose captures both differ from the baseline still blocks. A story marked Not checked for flakiness has not earned the non-blocking treatment.

You can still inspect, accept, or reject an unstable result. A rejection counts against the check. Its baseline remains unchanged unless the result is accepted.

Quarantine a recurring problem#

Owners and admins use Project settings → Flaky stories. The page lists unstable results and can suggest quarantine. Quarantined stories remain visible, but do not fail the check or block baseline advancement for other stories. Their baseline images are frozen.

Quarantine should accompany a tracked fix. It removes blocking coverage and should not be used simply to dismiss an unexplained regression.

Automatic quarantine and release#

You can enable automatic quarantine after a configured number of unstable results within a recent-run window. When automatic quarantine is off, the rule can suggest stories instead. Configure release after stable captures if you want automatic recovery, or release manually after fixing the story.

Changes apply to runs completed from then on. Releasing a story makes it count again from the next run; it does not retroactively rewrite old results.

Fix the source#

Common causes are random data, current time, missing fonts, animation, and live network responses. Work through stable stories and remove the quarantine once the result is reliable.