Parallel Checks

Parallel Checks let Mergify test multiple queued pull requests together so you ship faster. Mergify creates temporary draft PRs that represent cumulative merges (PR#1), (PR#1+PR#2), (PR#1+PR#2+PR#3), runs CI on them in parallel, then merges the original PRs once checks pass.

Mergify groups PRs by their position in the queue and the max_parallel_checks value. It creates draft PRs that speculatively combine changes and runs your CI on each in parallel. For example, with PR #1–#5 and max_parallel_checks: 3, Mergify creates:

• Draft #1: PR #1
• Draft #2: PR #1 + PR #2
• Draft #3: PR #1 + PR #2 + PR #3

This validates the combined outcome ahead of time against your queue_rules. If a draft fails, Mergify removes the culprit PR from the queue and continues with the rest.

The result: fewer head-of-line stalls, faster merges, and earlier detection of incompatibilities.

Set merge_queue.max_parallel_checks to control how many speculative checks run at once:

merge_queue:
  max_parallel_checks: 3

This example runs up to 3 speculative checks simultaneously. Tune this number to match your CI capacity and typical PR size/complexity.

Parallel Checks adapt automatically as your code and rules evolve:

• Failed checks: Mergify removes the failing PR and continues with the rest.

• PR or rule changes: affected PRs are re-evaluated and re-embarked in order.

• Base branch updates: checks restart on the new base; configurable via reset_on_external_merge — see Lifecycle: Base Branch Updates.

Flaky tests are a reality in most CI pipelines. A test that passes 99% of the time will still cause intermittent failures that block your merge queue. skip_intermediate_results provides automatic protection against these transient failures.

You have 3 PRs in the merge queue. PR #1’s CI fails due to a flaky test:

Draft #1 (PR #1):           ❌ Failed (flaky test)
Draft #2 (PR #1 + PR #2):   ✅ Passed
Draft #3 (PR #1 + #2 + #3): ✅ Passed

Without skip_intermediate_results: PR #1 gets dequeued. The developer investigates, finds nothing wrong, reruns CI, waits again. Time wasted.

With skip_intermediate_results: true: Mergify sees that Draft #2 (which contains PR #1’s code) passed. This proves PR #1’s failure was flaky, not a real bug. All 3 PRs merge automatically.

When enabled, Mergify doesn’t require every intermediate draft to pass. Instead, it looks for any passing draft that contains the PR’s changes:

1. Draft #1 fails (contains PR #1)

2. Draft #2 passes (contains PR #1 + PR #2)

3. Since Draft #2 passed and includes PR #1’s code, the failure in Draft #1 is treated as transient

4. Both PR #1 and PR #2 merge

This is safe because if PR #1 had a real bug, Draft #2 would also fail (it contains the same buggy code). Only flaky failures—where the code is fine but the test is unreliable—get bypassed.

Enable it in your merge queue configuration:

merge_queue:
  skip_intermediate_results: true

Enable when:

• Your CI has some flakiness (most pipelines do)
• You have long-running CI where latency matters
• You want to maximize merge throughput
• You’re using parallel checks

Consider disabling when:

• You need every intermediate state validated for compliance
• You’re debugging CI issues and want to see all failures

Mergify runs checks directly on the original pull request (instead of using temporary draft PRs) only when of the following are true:

• queue_rules[*].batch_size = 1

• merge_queue.max_parallel_checks = 1

• No two‑step CI is configured (i.e., no separate merge_conditions beyond queue_conditions in your queue rules)

• Optionally, set update_bot_account to avoid in‑place updates blocked by GitHub for security reasons (e.g., PRs from forks that modify workflows, or PRs opened by other bots)

Example configuration enabling in‑place checks:

merge_queue:
  max_parallel_checks: 1

queue_rules:
  - name: default
    batch_size: 1
    # use a single set of checks (no two‑step split between queue vs merge)
    queue_conditions:
      - check-success = ci
    update_bot_account: my-org-bot

Parallel checks operate by creating temporary pull requests, which merge multiple PRs with the base branch. This process requires the branch protection setting Require branches to be up to date before merging to be disabled.

This does not mean that Mergify will test outdated PRs, but it will merge the original pull requests once its parallel checks is finished. The original PR won’t be up-to-date according to GitHub, which means using this setting would block the merge.

Adjust max_parallel_checks to balance throughput and CI usage. Higher values increase concurrency; choose a value your CI can handle reliably. For deeper guidance and trade‑offs (including batching), see Merge queue performance.