> For the complete documentation index, see [llms.txt](https://docs.aviator.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aviator.co/api/reference/monitoring-metrics.md).

# Monitoring Metrics

Aviator provides monitoring metrics for Prometheus. Monitor your queue length and GitHub API usage.

Aviator provides some monitoring metrics for Prometheus. You can monitor your queue length and GitHub API usage with this.

## Endpoint

`https://app.aviator.co/api/metrics` serves Prometheus metrics. This is authed with your Aviator API key.

In Prometheus config, you can add a scrape config like this:

```yaml
scrape_configs:
  - job_name: "aviator-mergequeue"
    metrics_path: "/api/metrics"
    scheme: "https"
    params:
      # REQUIRED: repository names to expose
      repos:
        - "octocat/Hello-World"
        - "octocat/Spoon-Knife"
      # OPTIONAL: target branch names of the PRs (the merge destination).
      # If it's not specified, grab all PRs.
      branches:
        - "main"
    authorization:
      type: "Bearer"
      credentials: "mq_live_... YOUR API KEY HERE"
    static_configs:
      - targets:
        - "app.aviator.co"
```

You need to update the credentials part and the repository list part.

## Metrics

This endpoint exports following metrics.

<table><thead><tr><th width="292">Name</th><th width="84">Type</th><th width="79">Labels</th><th>Description</th></tr></thead><tbody><tr><td>mergequeue_queued_pr_count</td><td>Gauge</td><td>repo</td><td>Number of queued pull requests</td></tr><tr><td>mergequeue_reset_event_count</td><td>Counter</td><td>repo, branch, reset_type</td><td>Number of reset events over time</td></tr><tr><td>mergequeue_github_rest_api_quota_remaining_count</td><td>Gauge</td><td></td><td>Remaining quota for GitHub REST API</td></tr><tr><td>mergequeue_github_rest_api_quota_limit_count</td><td>Gauge</td><td></td><td>Max quota limit for GitHub REST API</td></tr><tr><td>mergequeue_github_graphql_api_quota_remaining_count</td><td>Gauge</td><td></td><td>Remaining quota for GitHub GraphQL API</td></tr><tr><td>mergequeue_github_graphql_api_quota_limit_count</td><td>Gauge</td><td></td><td>Max quota limit for GitHub GraphQL API</td></tr></tbody></table>

## Merge timing metrics

These describe how long pull requests take to get through the queue. These are not enabled by default. Please contact **<support@aviator.co>** to turn them on for your account; until then the endpoint serves only the metrics above.

<table><thead><tr><th width="292">Name</th><th width="98">Type</th><th width="150">Labels</th><th>Description</th></tr></thead><tbody><tr><td>mergequeue_time_to_batch_seconds</td><td>Histogram</td><td>repo, branch</td><td>Seconds from queue entry to batch creation</td></tr><tr><td>mergequeue_time_to_merge_seconds</td><td>Histogram</td><td>repo, branch</td><td>Seconds from the final queue entry to merge</td></tr><tr><td>mergequeue_cumulative_queue_seconds</td><td>Histogram</td><td>repo, branch</td><td>Seconds spent in the queue across every attempt</td></tr><tr><td>mergequeue_base_updates</td><td>Histogram</td><td>repo, branch</td><td>Base branch updates applied to a pull request before it merged</td></tr><tr><td>mergequeue_merged_pr_count</td><td>Counter</td><td>repo, branch, merged_by</td><td>Number of merged pull requests, split by whether the queue merged them</td></tr><tr><td>mergequeue_metrics_rollup_age_seconds</td><td>Gauge</td><td>repo, branch</td><td>Seconds since these timings were last recomputed</td></tr></tbody></table>

### Which duration to use

The three durations answer different questions, and the gaps between them are where the useful signal is.

* `mergequeue_time_to_batch_seconds` is how long a pull request waited for a slot. It grows when the queue is deeper than your build concurrency.
* `mergequeue_time_to_merge_seconds` covers that wait plus the batch's CI run, measured from the pull request's most recent queue entry. Subtracting the first from the second leaves the CI time.
* `mergequeue_cumulative_queue_seconds` adds up every attempt, so it also counts the time spent on attempts that were reset. The gap between it and `mergequeue_time_to_merge_seconds` is time lost to resets.

A pull request re-entering the queue restarts the clock behind the first two, so both describe the attempt that succeeded. Only `mergequeue_cumulative_queue_seconds` spans the earlier ones.

### What to expect on the first scrape

These are computed in the background rather than on the scrape itself, and a repository has nothing cached until it is first scraped. The first scrape after enabling the add-on therefore returns the other metrics but none of these; the next one has them. Values accumulate from that point forward and are not backfilled, so a dashboard covering the first few minutes will look empty.

`mergequeue_metrics_rollup_age_seconds` reports how old the served values are. Under normal conditions it stays under a few minutes; a sustained climb means the values are stale and is worth alerting on.

### Limit on repositories and branches

One request serves at most 100 repository and branch combinations. Past that the extra pairs are dropped, so split large repository lists across several scrape jobs rather than requesting them all at once.

### Note on metric names

You will likely see metrics with some suffixes like `_total` and `_created`. This is Prometheus ecosystem's convention that we need to follow. See [the OpenMetrics format spec](https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md) for details.

## See Also

* [How to Collect Prometheus Metrics in GCP](/api/how-to-collect-monitoring-metrics-in-gcp-prometheus.md)
* [How to Collect Metrics in Datadog](/api/how-to-collect-monitoring-metrics-in-datadog.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.aviator.co/api/reference/monitoring-metrics.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.