---
title: Monitoring your Merge Queue
description: Monitor key metrics of your merge queue to improve throughput and reduce latency.
---

The Mergify dashboard reports how your merge queue has performed over time, and
the Mergify CLI reports what it is doing right now.

## The Statistics Page

Open **Merge Queue → Statistics** in your
[dashboard](https://dashboard.mergify.com) to see how your queue is behaving:

<Image src={dashboardStatsScreenshot} alt="Statistics page on Mergify's dashboard"/>

Use the date picker to select the time range you want to review. Presets go up to
"Past 3 months". Queue data is retained for 90 days: the calendar will not let you
pick a day older than that, and the oldest day or two of the longest preset can
come back empty.

Three controls apply to every widget on the page at once:

- The **repository selector** chooses which repository the page reports on.

- **Filters** restrict the data to a set of branches,
  [queue rules](/merge-queue/rules), or
  [priority rules](/merge-queue/priority).

- **Breakdown** keeps all the data but splits each chart into one series per
  branch, queue rule, or priority rule, so you can compare them side by side.
  Clicking a series narrows the page down to it. **Max Running Checks** is the
  one widget that cannot be broken down by priority rule: a running check covers
  a batch of pull requests that may come from different priority rules, so it
  cannot be attributed to a single one.

A row of headline figures sits at the top: pull requests entered and merged, the
merged rate, the share of queue time spent waiting for CI capacity, max queue
size, throughput, queue time, CI runtime, and CI failure rate. Below it, the
widgets are grouped into three sections.

### Queue Health

Exit reasons, interruptions, and failure trends.

- **PR Exit Reasons**: how pull requests leave the queue. The distribution view
  counts each pull request once by its final exit reason; the over-time view
  shows how those reasons trend.

- **Batch Outcomes**: the outcome of every CI run the queue triggered, including
  batch results, [bisection](/merge-queue/batches#handling-batch-failure-or-timeout)
  attempts, and queue resets. One pull request can produce several runs.

- **Checks Retries**: how often checks are retried, and how often a retry ends in
  a merge. A low recovery rate points at genuinely broken tests rather than
  flaky ones.

- **CI Failure Rate**: the share of queue CI runs that failed. A rising rate
  usually means flaky tests, unstable CI, or problematic changes being queued.

- **Batch Bisection Count**: how often Mergify had to split a failing batch to
  find the culprit. A high count means batches are failing often.

### Throughput

Volume of pull requests processed and queue capacity.

- **Entered PRs** and **Merged PRs**: how many pull requests joined and left the
  queue over time. Sudden drops or spikes are worth investigating.

- **Max Queue Size**: the largest the queue got. The reference line marks your
  max checks capacity (max batch size ×
  [`max_parallel_checks`](/merge-queue/performance#parallel-checks)), so a queue
  above the line means pull requests are waiting for a free check slot.

- **Average Batch Size**: the reference line shows the largest
  [`batch_size`](/merge-queue/batches) configured across your queue rules. Sitting
  at the maximum suggests the queue is saturated.

- **Max Running Checks**: peak concurrent checks. The reference line is your
  effective `max_parallel_checks` (the configured value, or the default when it
  is unset). If you are often at that line, raising `max_parallel_checks`
  improves throughput.

### Performance

Queue timing and CI execution speed.

- **Time Breakdown**: how a pull request's time in queue splits across waiting
  for CI capacity, [schedule](/configuration/data-types#schedule) windows,
  [freeze](/merge-protections/freeze) periods, and CI runtime. Switch each
  component between **Avg**, **P95**, and **Max** to see whether the queue is
  usually fast with rare spikes or consistently slow. Only the average is
  additive, so the total in the center is shown for **Avg** only. If capacity
  wait dominates, raise `max_parallel_checks`.

- **Average Queue Time**: the full time a pull request spent in the queue.

- **Average CI Runtime**: how long your CI takes. An increase here slows the
  whole queue down.

- **Batches Saved**: batches that merged without running their own speculative
  checks, because a later batch containing their changes had already passed. Each
  one is a CI run the queue avoided. This requires
  [`skip_intermediate_results`](/merge-queue/batches#skip-intermediate-results-anti-flake-protection)
  on the queue.

## Monitoring the Queue with the CLI

You can check your merge queue status from the command line with the Mergify
CLI. The [`queue` CLI reference](/cli/queue) lists every command and flag.

```bash
mergify queue status
```

This displays:

- **Pause status**: whether the queue is paused, with reason and elapsed time

- **Batches**: batches organized by scope with status indicators and their
  pull requests

- **Waiting PRs**: queued pull requests with priority, queue time, and
  estimated merge time

To filter results to a specific branch:

```bash
mergify queue status --branch main
```

Use `--json` for machine-readable output:

```bash
mergify queue status --json
```

### Inspecting a Pull Request

To see the detailed state of a specific pull request in the queue:

```bash
mergify queue show <pr_number>
```

This displays the PR's position, priority, queue rule, CI checks summary, and
blocking conditions. See the
[`mergify queue show` reference](/cli/queue#mergify-queue-show) for its flags.

## Integrations

<Monitoring />

You can also build your own monitoring solution using the Mergify
[API](/api/usage).