Skip to main content
Sometimes a pull request fails in the queue not because of its code or tests, but because of a problem on GitHub’s side. When that happens, Trunk Merge Queue removes the PR from the queue and posts a failure message that links to one of the sections below. Each section explains what the message means, what Trunk already tried, and how to get your PR merged. In most cases the fix is the same: confirm GitHub is healthy at githubstatus.com, then re-submit the PR the same way you normally enqueue it. See Handle failed pull requests for all the ways to re-queue a PR.
Visit Trunk Support for additional assistance or to contact the support team.

​
GitHub server errors

GitHub’s API repeatedly returned server errors, so it could not be merged.
When Trunk called GitHub’s merge API, GitHub responded with server errors (HTTP 500, 502, 503, or 504). These errors come from GitHub’s infrastructure, not from your PR or your queue configuration. Trunk already retried the merge automatically — 10 attempts over roughly 60 seconds — and only declared the failure after every attempt returned a server error. To resolve:
  1. Re-submit the PR. This was most likely a brief blip on GitHub’s side, and re-submitting usually succeeds.
  2. If it fails again, check githubstatus.com for an active incident affecting Pull Requests or the API. If there’s an incident, wait for it to resolve before re-submitting.
  3. If GitHub’s status is green and the failure keeps happening, contact help@trunk.io with a link to the affected PR.

​
Merge already in progress

GitHub repeatedly reported that a merge was already in progress.
GitHub returned HTTP 405 with the message “Merge already in progress” — meaning GitHub considers a merge of this PR to already be underway. This typically starts with GitHub returning a server error (such as a 503) on the first merge attempt; on every retry after that, GitHub reports that the first attempt is still in progress on its side. Trunk retried automatically — 10 attempts over roughly 60 seconds — before declaring the failure.
Even though GitHub reported the merge as failed, it may have actually merged your PR. GitHub’s answer reflects its state at that moment, and that state can lag behind what actually happened. Before you re-submit, check the base branch’s commit history for your PR’s commit.
This failure can leave your PR in one of three states. To figure out which one you’re in, open the base branch’s commit history in GitHub (Code → Commits on the base branch) and look for a commit referencing your PR number: 1. The PR is open and your commit is not on the base branch. The merge genuinely didn’t happen. Wait a moment for GitHub to settle, then re-submit the PR. If the queue is empty and you’re in a hurry, you can also merge the PR directly in GitHub. 2. The PR is open but your commit is on the base branch. GitHub pushed the merge commit even though it reported the merge as failed, and hasn’t yet marked the PR as merged. Do not re-submit — the change is already in. Either wait for GitHub to catch up and mark the PR merged, or manually close the PR. (A manually closed PR shows as “Closed” rather than “Merged” in GitHub — that’s cosmetic; your commit is on the base branch either way.) 3. The PR shows as closed or merged (possibly only for some viewers). The merge went through and GitHub’s UI is catching up — different people may briefly see different states for the same PR. No action needed; the PR’s state will converge on its own. If this keeps happening: contact help@trunk.io with a link to the affected PR. This error comes from GitHub’s side, and we can raise repeated occurrences with GitHub.

​
GitHub error starting tests

It repeatedly encountered a transient GitHub error.
This failure happens while Trunk is starting tests for your PR, not while merging it. To test a PR, Trunk prepares a test branch through the GitHub API, and those API calls repeatedly hit transient errors. The most common cause is GitHub API rate limiting (HTTP 429 — either the primary rate limit or secondary/concurrency limits); GitHub can also return transient 422 errors during branch preparation. Trunk retried about 3 times over roughly 90 seconds before declaring the failure. To resolve:
  1. Wait a few minutes for the rate-limit window to reset, then re-submit the PR. This resolves most cases.
  2. Check githubstatus.com to rule out a GitHub incident.
  3. If the failure persists, contact help@trunk.io with a link to the affected PR. Rate limits apply org-wide and you can’t easily see what’s consuming them — we can help figure out whether the queue’s own activity, other automation, or something on GitHub’s side is responsible.

​
GitHub rejected merge

GitHub returned the following error when attempting to merge it - <error>.
GitHub rejected the merge for a non-transient reason and returned an error message, which Trunk shows verbatim in the failure. Unlike the failures above, retrying won’t help until the underlying cause is fixed. The most common cause is branch protection rules or repository rulesets that aren’t satisfied — required approvals, required status checks, or a branch-must-be-up-to-date requirement. To resolve:
  1. Read the GitHub error text included in the failure message — it names the specific requirement that wasn’t met.
  2. Fix the underlying cause: get the required approvals, make the required checks pass, or update your branch with its base.
  3. Re-submit the PR.
Common GitHub error messages and their fixes: Some of these fixes require repository admin access (merge settings, branch protection rules) — if you don’t have it, share this page and the error with a repo admin. If the error you received isn’t listed here and the cause isn’t clear, contact help@trunk.io with the full failure message.