View as Markdown

Using Datadog with Mergify

Send your merge queue metrics to Datadog to build dashboards, alerts, and reports alongside the rest of your observability data.


The Datadog integration pushes your merge queue metrics into your own Datadog account. Everything on the merge queue statistics page is available as a Datadog metric, so you can graph queue health next to your own service metrics and alert on it.

The integration is official and ships as a Mergify tile in Datadog’s integration catalog. Mergify writes the metrics to Datadog for you. There is no agent to install and nothing to run in your CI.

  • A Datadog account, and permission to authorize integrations in it.

  • On the Mergify side, a plan that includes the Datadog integration, plus the GitHub organization Owner role or the Integrations Admin delegated role.

  1. In the Mergify dashboard, go to Integrations → Datadog. Installing the Mergify tile from Datadog’s integration catalog and clicking Connect Accounts lands in the same place.

    The Datadog integration in the Mergify dashboard's integrations list
  2. Connect your Datadog account. Pick the Datadog site your organization uses (US1, US3, US5, EU1, US1-FED, or AP1), then authorize Mergify. Mergify creates an API key scoped to the integration and starts pushing metrics to that site.

  3. Choose what to monitor. For each repository, select the merge queue base branches you want metrics for: the branches your queued pull requests target, such as main or a release branch.

Every metric is published every 5 minutes, and each point covers the 5-minute window it represents.

Every metric carries these tags:

TagDescription
repositoryFull repository name, such as octo/hello-world
branchThe base branch the queued pull requests target
queueName of the queue rule
priority_ruleName of the matching priority rule, when set

Metrics submitted as count are event tallies that Datadog sums exactly over any time range. Metrics submitted as gauge are peak values within the window.

MetricTypeDescription
mergify.queue.enteredcountPull requests that entered the queue
mergify.queue.mergedcountPull requests merged out of the queue
mergify.queue.exit_reasoncountPull requests that left the queue, tagged with exit_reason
mergify.queue.size.maxgaugeLargest the queue got
mergify.queue.running_checks.maxgaugeMost checks running at once
mergify.queue.check_outcomecountFinished queue checks, tagged with outcome
mergify.queue.checks_retries.recoveredcountFailed checks that passed on retry
mergify.queue.checks_retries.not_recoveredcountFailed checks that failed again on retry
mergify.queue.bisection.startedcountBatch bisections started
mergify.queue.total_queue_time.sumcountTotal time queued, in seconds
mergify.queue.total_queue_time.countcountQueue sessions the sum covers
mergify.queue.ci_runtime.sumcountTotal CI runtime, in seconds
mergify.queue.ci_runtime.countcountCI runs the sum covers
mergify.queue.batch_size.sumcountTotal pull requests across batches
mergify.queue.batch_size.countcountBatches the sum covers
mergify.queue.breakdown.ci_runtime.sumcountQueued time spent running CI, in seconds
mergify.queue.idle.capacity.sumcountQueued time spent waiting for capacity, in seconds
mergify.queue.idle.schedule.sumcountQueued time spent waiting for a schedule, in seconds
mergify.queue.idle.freeze.sumcountQueued time waiting on a freeze, in seconds
mergify.queue.idle.countcountQueue sessions the breakdown sums cover

Both outcome and exit_reason are success when the pull request merged or its checks passed. Otherwise they name the reason the pull request left the queue or its checks were aborted, such as checks_failed or pr_dequeued. The integration’s README lists every value.

The duration and size metrics ship as a .sum and a .count rather than a pre-computed average, so Datadog can recompute the real average over whatever time range you graph. Divide a family’s own sum by its own count:

sum:mergify.queue.total_queue_time.sum{$repository} / sum:mergify.queue.total_queue_time.count{$repository}

The same shape gives you average CI runtime (mergify.queue.ci_runtime.*) and average batch size (mergify.queue.batch_size.*).

The share of failed checks that passed when retried:

sum:mergify.queue.checks_retries.recovered{$repository} / (sum:mergify.queue.checks_retries.recovered{$repository} + sum:mergify.queue.checks_retries.not_recovered{$repository})

Total queued time splits into CI runtime plus three kinds of waiting:

mergify.queue.breakdown.ci_runtime.sum # running CI
mergify.queue.idle.capacity.sum # waiting for a free check slot
mergify.queue.idle.schedule.sum # waiting for a schedule to open
mergify.queue.idle.freeze.sum # waiting for a freeze to lift

Graphed together as a stacked area, they show what your queue is actually waiting on. Divide any of them by mergify.queue.idle.count for a per-pull-request average.

Because the three idle.* metrics are pure waiting time, sum:mergify.queue.idle.*.sum gives you total wasted time without counting CI.

The Mergify - Merge Queue Stats dashboard in Datadog

The Mergify tile ships a Mergify - Merge Queue Stats dashboard that mirrors the merge queue statistics page. In Datadog, open the Mergify integration page and find it under the Monitoring Resources tab. Clone it to adapt it to your own repositories, or build your own from the metrics above.

Since the metrics are ordinary Datadog metrics, you can alert on them with monitors. Useful ones to start with:

  • mergify.queue.size.max staying above a threshold, which usually means CI capacity is the bottleneck.

  • Average queued time trending up week over week.

  • Check retry recovery rate dropping, which points at genuinely broken tests rather than flaky ones.

  • mergify.queue.exit_reason counting anything other than success, which means pull requests are leaving the queue without merging.

Was this page helpful?