Queue Analytics
A merge queue without analytics is a black box. You know PRs go in and PRs come out, but you cannot tell whether the queue is paying for itself or quietly slowing the team down. Analytics is the answer to "what is our queue actually doing?"
In one paragraph
Queue analytics is the set of numbers that show what your merge queue is doing: throughput, wait time, batch success rate, failure rate, and where time is spent inside the queue. The point is not the dashboard. The point is the decisions the dashboard unlocks. Tune batch size when batch success drops. Investigate the CI suite when wait time climbs. Turn on speculative checks when serial throughput caps out. Without the numbers, those calls happen on gut feel.
The metrics that matter
Most queue dashboards show too many numbers. Five of them carry the signal. The rest are noise unless you are debugging a specific incident.
1. Throughput
How many PRs the queue merges per hour, per day, or per week. The headline number. Track the trend, not the absolute value. A team merging 40 PRs a day has very different expectations from one merging 4.
2. Wait time
Time from when a PR enters the queue to when it merges. Look at p50 and p95. Under 30 minutes p50 is healthy. Past 60 minutes p95 and engineers start context-switching while their PR sits.
3. Batch success rate
Percent of speculative batches that pass the first time. Above 80% means batching is winning: fewer CI runs, faster merges. If it drops below 60%, the batches are too large for the failure rate of your suite. Cut the batch size or fix the flaky tests driving the failures.
4. Failure rate
Percent of queued PRs that get rejected. A few percent is normal and is the queue doing its job. Spikes mean something changed: a flaky required check, a regression on main, a misconfigured rule.
5. Stage breakdown
Where time goes inside a queued PR's life. Waiting for a slot in the queue is different from waiting for CI to finish. Most queues split into "queued" (waiting for the front of the line), "testing" (CI running), and "merging" (waiting for the merge commit to land). If most of your wait time is "queued," batching helps. If most of it is "testing," your CI suite is the bottleneck and a queue alone will not fix it.
What the numbers tell you to do
Each metric pairs with a specific action. If you find yourself looking at a dashboard with no action in mind, you are reading it wrong.
- Wait time climbing, throughput flat: something added latency to the queue without changing volume. Likely a slow check, a regressed CI step, or a runner pool issue. Look at the stage breakdown to confirm.
- Batch success rate dropping: the suite has gotten flakier or batches are too large. Cut batch size, then chase the flaky checks. The flaky tests guide covers the fixes by framework.
- Failure rate spiking: something is breaking on main or in a required check. Check whether failed PRs share a file or a check. A single bad PR can run up the failure count for everything behind it in a serial queue.
- Throughput capped despite low wait time: the queue is starving. PRs are not being added fast enough. Usually a problem upstream of the queue (slow review, missing approvals, manual queue-add step).
- Wait time stable but batch success too low: bisection is eating the savings. Mergify's batch failure view shows which PR in the batch caused the failure, so you do not pay the bisection round in the dark.
Queue analytics in real tools
GitHub's native merge queue has effectively no analytics. The current state of the queue is visible in the UI, but there is no built-in dashboard for throughput, wait time, or batch outcomes. Teams that want the numbers either scrape the Checks API themselves or move to a queue tool that ships analytics. The full side-by-side lives at Mergify vs GitHub merge queue.
Mergify ships queue analytics as part of the merge queue product. The dashboard surfaces throughput, wait time, batch outcomes, and per-stage time, with a queue-wide event log for debugging individual PR lifecycles. Alerting on the metrics that matter (stalled queue, wait time past a threshold, elevated failure rate) is one rule each. See Mergify Merge Queue for the product page.
FAQ
What is queue analytics?
Queue analytics is the set of metrics and dashboards that show what a merge queue is actually doing: how long PRs wait, how many merge per hour, how often a batch fails and forces a re-test, and how often the queue is blocked by a single bad PR. Without it, the queue is a black box that you can only judge by gut feel.
What metrics does a merge queue expose?
The useful ones are throughput (PRs merged per hour or per day), wait time (from queue entry to merge), batch success rate (percent of speculative batches that pass the first time), failure rate (percent of queued PRs rejected), and time-to-merge broken down by queue stage. Most queue tools also expose per-PR event logs for debugging.
Does GitHub merge queue have analytics?
Not really. GitHub's native queue exposes the current state of the queue and the standard GitHub Actions run history, but there is no built-in dashboard for throughput, wait time, or batch outcomes. Teams that want those numbers either scrape the Checks API themselves or move to a queue tool that ships analytics.
What is a good queue wait time?
Under 30 minutes p50 is healthy for most teams. Past 60 minutes p95, engineers start to context-switch and the queue becomes a tax on the day. The single biggest lever is batching combined with two-step CI: lightweight checks on the PR, heavy checks only in the queue, multiple PRs per CI run.
How do I tell if my batching strategy is working?
Look at two numbers: batch success rate and the average batch size. A success rate above 80% means batching is winning (fewer CI runs, faster merges). If success rate drops, your batches are too large for the failure rate of your suite. Mergify's queue dashboard surfaces both, and the same view exposes per-batch bisection cost so you can see what a failure actually costs.
Should I alert on queue metrics?
Yes, but selectively. Alert on queue stalled (no merges in N minutes despite ready PRs), wait time exceeding a threshold, and elevated failure rate. Avoid alerting on every failed batch since failures are a normal part of how a queue protects main.
See your merge queue in numbers, not gut feel.
Mergify ships queue analytics in every plan: throughput, wait time, batch outcomes, stage breakdown, and per-PR event log.