Fail First

A failed batch is the slow path of a merge queue: to find the pull request that broke it, Mergify tests smaller splits of the batch, and each one used to run your whole suite before it could go red. With Fail First, the splits holding the culprit go red after a few tests and give their CI runner back. On a real run of a 96-test suite, they stopped after 3 tests, in 14 to 17 seconds, where the splits without the culprit took about 70 seconds to pass. No test is ever skipped to turn a split green: a split that passes has run your whole suite.

• In your CI log: the plugin says how many tests ran first and, when a split stops early, which ones failed again and how many did not run.
• On Test Engine › Configuration: a Fail First section shows whether it is active and on which jobs, how many splits ran with it and how many stopped early over the last 30 days, and an estimate of the CI time saved.
• For jobs that cannot use it yet: the same section names the jobs that send JUnit reports only or run an older plugin, and offers to install or update the plugin on them.
• Everywhere else: pull request CI, the batch’s own run and retries keep your usual test order. Fail First needs a merge queue that uses batches and the Mergify plugin for your test framework (pytest, RSpec, Minitest, Vitest, Jest, Mocha or Playwright) at version 2026.10.8 or later. From that version it is on, with nothing else to add to your jobs. If some of your tests depend on the order they run in, set MERGIFY_FAIL_FIRST_ENABLE to false on those jobs to keep their usual order. Read how Fail First works.