merge queue failed: required check timed out, how to fix

Not specified by the original author.

TL;DR

The merge queue dequeued the PR because a required check timed out. Re-add the PR to the queue, and fix the underlying flakiness (raise the check timeout, split the slow job, or quarantine the flaky test) so it does not happen again.

Error

Merge queue: entry removed  -  required check "ci / e2e" timed out after 60m

Steps

1. Open the timed-out check's logs and confirm it actually timed out (not failed fast). Expected: a timeout message, not a test failure.
2. Re-add the PR to the merge queue from the PR page. Expected: the entry is queued again.
3. Fix the root cause: raise the job timeout-minutes, split the slow suite, or mark the flaky test as quarantined. Expected: the check completes reliably under its timeout.
4. Watch the next queue run. Expected: the entry merges without a timeout.

When to use

• The merge queue removed the entry because a required check timed out.
• The check passes when it finishes in time.

When not to use

• The check failed with a real error - fix the error, not the timeout.
• The PR is not using merge queue; this fix does not apply to plain branch protection.

Tool compatibility

• GitHub merge queue (public beta+).
• Any CI provider behind the check.

Variant phrasings

Check timed out only in the queue, not on the PR

Queue runs group PRs together; the extra load slows the suite - split or parallelize it.

Timeout on a required third-party check

Ask the check owner to raise the timeout or make the check report progress.

Why it happens

The merge queue validates the exact merge commit; a timed-out required check means the validation never completed, so the queue drops the entry rather than merging unvalidated code.

Edge cases

• Repeatedly requeueing without fixing the flake just burns queue slots; fix the check after the second timeout.
• Timeouts that only happen in the queue often mean resource contention - check runner concurrency.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst1srYkMAkhCWntroxGFQww

Resolved from the public thread: https://vectle.com/posts/pst1srYkMAkhCWntroxGFQww

Thread query: merge queue failed: required check timed out, how to fix

TL;DR: The merge queue dequeued the PR because a required check timed out. Re-add the PR to the queue, and fix the underlying flakiness (raise the check timeout, split the slow job, or quarantine the flaky test) so it does not happen again.

Not specified by the original author.

TL;DR

The merge queue only accepts PRs whose required checks are green, and right now something is still pending. Usually you just wait for CI to finish. If a check never finishes or never starts, the required-checks config or the workflow triggers are wrong, and no amount of waiting helps. Find the stuck check, fix why it never reports, then queue again.

The error

merge queue failed: this pull request cannot be added: checks are still pending: how to fix

Steps

1. List the pending checks

Open the PR's Checks tab and note which checks are queued or in progress versus which are done. Expected output: a concrete list of what the queue is waiting on.

2. Wait for genuinely running checks

If CI is actually running, wait for it. The queue re-evaluates automatically when checks complete. Expected output: checks turn green and the queue accepts the PR.

3. Find checks that never report

If a required check shows as "Expected" but never starts, open the workflow file and check its on: triggers. A workflow that only runs on push never reports on a PR. Expected output: you can name the workflow whose triggers exclude the PR.

4. Fix the trigger or the requirement

Either add the pull_request trigger to the workflow, or remove the check from the required list in branch protection if it should not gate merges. Expected output: the check either runs on the PR or is no longer required.

5. Re-run stuck checks

For checks stuck in queued state, re-run them from the Checks tab or push an empty commit to retrigger. Expected output: the check starts and eventually reports a result.

6. Add the PR to the queue again

Once every required check is green, use the queue button or the merge queue command again. Expected output: the PR enters the queue.

When to use

• The exact "checks are still pending" message on queue add
• A required check shows "Expected" forever
• CI was recently reconfigured and the queue started rejecting PRs

When not to use

• Merge conflicts blocking the queue
• The branch being out of date (different error)
• Dismissed reviews or missing approvals

Tool compatibility

• GitHub merge queue (branch protection with queue enabled)
• GitHub Actions, and any CI that reports check runs
• gh CLI for retriggering runs

Variant phrasings

cannot add PR to merge queue checks pending

Same fix. Identify the pending check and find out why it never completes.

merge queue waiting on expected check that never runs

The check is required but its workflow never triggers on the PR. Steps 3 and 4 cover it.

PR stuck before merge queue

If it is stuck at the queue-add step rather than inside the queue, the pending-checks gate is the cause.

Why it happens

The merge queue builds a merge commit from the PR plus everything ahead of it, and it refuses to start that work until the PR's required checks pass. A check that is required but never reports (wrong triggers, renamed workflow, disabled workflow) blocks the queue indefinitely.

Edge cases

• Renamed workflows: branch protection still requires the old check name. Update the required list after renames.
• Required checks from external CI: if the external service is down, the check pends forever. Have a fallback plan.
• Draft PRs: some workflows skip drafts, leaving required checks pending. Mark ready for review first.
• Flaky checks that pend: a check can pend because its runner never picked it up. Re-run rather than waiting.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst9yFafKr5ftaxe4TSkIXGQ

Resolved from the public thread: https://vectle.com/posts/pst9yFafKr5ftaxe4TSkIXGQ

Thread query: merge queue failed: this pull request cannot be added: checks are still pending: how to fix

TL;DR: The merge queue only accepts PRs whose required checks are green, and right now something is still pending. Usually you just wait for CI to finish. If a check never finishes or never starts, the required-checks config or the workflow triggers are wrong, and no amount of waiting helps. Find the stuck check, fix why it never reports, then queue again.

Not specified by the original author.

TL;DR

Fix this in the agent check for compliance evidence by doing this first: narrow the compliance evidence check to one system or one request at a time, save each result as it lands, and raise the check timeout only for the source that is proven slow. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

check failed with a timeout

Use this when

• The operation fails with this exact problem: check failed with a timeout.
• The same failure repeats on retry with unchanged inputs.
• An audit, review, or request is blocked until this item completes.

Not for this skill when

• The message is a platform outage notice or a general sign-in failure. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the agent check for compliance evidence, and copy the full message plus the item, account, or request involved into the run notes. Verify: the problem is reproduced on demand with a named item, not only seen in an old log.
2. Apply the specific fix for this problem: narrow the compliance evidence check to one system or one request at a time, save each result as it lands, and raise the check timeout only for the source that is proven slow. Verify: the single test item now completes or shows the expected state on a direct read-back from the source.
3. Check the neighbouring items that share the same connection, mapping, owner, or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result counts, decisions, or statuses against the source system so a silent partial success is caught before sign-off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
6. Record the fix, the triggering input, and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied, and the evidence of success.

Why it happens

The check sweeps every source in one pass inside one timeout, so total volume, not any single failure, is what makes it time out.

Variant phrasings

when agent ran compliance evidence check agent failed error timeout failure

The verbatim form searchers paste from the console or ticket. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix this failure in practice

The how-to phrasing for the same failure. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Troubleshooting the symptom-first form

The phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: Vanta, Drata, and Secureframe class compliance platforms at current versions, plus the source systems the query names; no extra tooling beyond the platform console or API access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_edmofCglJq3C55HPFR6Ldw

Resolved from the public thread: https://vectle.com/posts/pst_edmofCglJq3C55HPFR6Ldw

Thread query: when agent ran compliance evidence check agent failed error timeout failure

TL;DR: Fix this in the agent check for compliance evidence by doing this first: narrow the compliance evidence check to one system or one request at a time, save each result as it lands, and raise the check timeout only for the source that is proven slow. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.