Merge queue: option to tolerate CI retries before dequeuing

[altendky]

Problem

When a PR is being validated in the merge queue and CI fails due to a flaky test or transient infrastructure issue, the PR is immediately dequeued. This requires manual intervention (@mergifyio queue or @mergifyio refresh) to get the PR back into the queue, even when the failure is transient and a retry would succeed.

This is a common pain point (see #4008, #5044) and becomes especially frustrating in projects where flaky tests or CI infrastructure hiccups are a fact of life.

Current workarounds

• CI Insights Auto-Retry: Can automatically retry failed GitHub Actions workflows, but it's unclear how this interacts with the merge queue's dequeue decision. If the merge queue dequeues the PR before Auto-Retry has a chance to re-run and succeed, the retry is wasted.
• autoqueue: true: A dequeued PR can be re-enqueued automatically if it still matches queue_conditions, but this requires a fresh CI run from scratch rather than waiting for an in-flight retry to complete.
• GitHub Actions built-in retries: Step-level retries within workflows help, but don't cover job-level or workflow-level transient failures.

Suggestion

It would be valuable if the merge queue could be made aware of retry attempts before deciding to dequeue a PR. Some possible approaches (open to Mergify's perspective on what fits best):

• A queue rule option (e.g., max_check_retries) that tells the merge queue to retry CI validation N times before dequeuing
• Integration with CI Insights Auto-Retry so the merge queue waits for configured retries to be exhausted before dequeuing
• A configurable grace period after a check failure during which the queue holds the PR's position, allowing external retry mechanisms to kick in

The key idea is: don't dequeue until retries have been given a chance to succeed.

Context

We run into this with a mix of flaky tests and transient infrastructure failures. Our current config uses autoqueue: true with checks_timeout: 90 min, but once a check reports failure the PR is dequeued immediately regardless of the timeout.

[jd]

We're going to release max_check_retries in a few days. Stay tuned.

[altendky]

thanks!

[jd]

Here it is: https://docs.mergify.com/changelog/2026-03-18-automatic-ci-retries-in-merge-queue/

[altendky]

thanks. i'll adjust my settings and give it a try.

have you considered an option for re-running just the failed jobs similar to ci insights if i remember correctly?

[jd]

Unfortunately, there's no standard way to retrigger any CI (there's a wide variety) on a particular PR, so that makes it hard. We're still looking for solution for this, but no silverbullet for now.

CI Insights can do that indeed and that's easier since it operates as the CI level.