> For the complete documentation index, see [llms.txt](https://docs.revenium.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.revenium.io/track-and-control-costs/analyze-ai-tooling-spend/pr-health.md). # PR Health Find the pull requests that are stuck, abandoned or going stale, and the AI spend behind them. **In the product:** `https://app.revenium.ai/ai-assistants/pr-health`, or **Intelligence > AI Assistants > PR Health**. PR Health shows which pull requests need a decision, which were abandoned, and how much coding-assistant spend sits behind them. Setup steps are shown on screen; this page covers what PR Health needs, how it works, and how to read it. ## What it needs * **GitHub**, connected under **Integrations > Integrations** tab **> Connect GitHub** or through the Revenium GitHub App. See the [GitHub integration guide](/track-and-control-costs/analyze-ai-tooling-spend/github-integration.md). PR Health reads GitHub pull requests only. * **A coding assistant**, such as [Claude Code](/track-and-control-costs/analyze-ai-tooling-spend/setup-claude-code.md), for the dollar figures. Without one, PR Health still counts pull requests but shows no estimates. * **Assistant attribution** on commits or pull request descriptions, for the AI-assisted figures. Your administrator can enforce it by adding the commit and pull request attribution lines to your managed Claude Code settings. A ticket key in a pull request's title or head branch shows that ticket on the pull request's row, for tickets that Revenium's Developer Cost Toolkit has already tied to your team's coding work. ## Before GitHub is connected Until you connect a GitHub organization, PR Health shows sample data behind a **You're viewing sample PR health data** notice, and a **Sample data, not from your account** label stays at the bottom of the page. None of those figures come from your account. The same sample view, with a note that says what is missing, appears when your organization is connected only to GitLab, while the first sync is still pending, and when the GitHub connection needs attention before its first successful sync. ## How it stays current A new GitHub connection, or a change to its repositories or AI co-author patterns, first loads up to 90 days of pull requests in hourly passes. While that runs, PR Health shows **GitHub is still loading pull requests** above the figures, and **Still loading, last pass …** under the page controls: the numbers are partial until the load completes. After that, GitHub data refreshes once a day, around 03:00 UTC. **Last synced** under the page controls shows when the data was last refreshed, and **Sync now** refreshes it straight away; while a scheduled pass is running, it says so instead of starting another. If the queue stays empty after a sync, check the token's pull request permission and the selected repositories, then open **View Sync Logs** on the Integrations tab and select **Failures** to see any failed run and its suggested next step. ## Reading the numbers The line under the page title states the rules behind every figure: which pull requests are included, when dollar estimates start, and the aging and rotting thresholds. Select a part of it to open **Settings** at that rule. Every dollar figure is an estimate, never an amount billed for a single pull request. On **Overview** and in the queue, each pull request is priced at **Cost per PR**: the organization's coding-assistant spend divided by its pull requests that were open at the end of the period, closed without merging in it or merged in it. Automation pull requests are left out. If there are no pull requests in that basis or no coding-assistant spend was recorded, the page shows no dollar estimate. On **Engineers**, **AI spend** is each engineer's own recorded coding-assistant spend in the period, and the at-risk and wasted dollars split that spend by the engineer's share of rotting or closed pull requests; the **Departments** view adds those up by department. ### Overview: what needs a decision this week? Start here to clear the backlog. **Fix this week** sorts open pull requests by what they need, each with its estimated spend and the action to take: **Waiting on review** (assign a reviewer), **Approved, not merged** (merge or close), **Stuck drafts**, **Changes requested, quiet** (nudge the author) and **Author gone** (close or reassign). Automation pull requests are listed but not counted. Below the cards, **Wasted** is the spend on pull requests closed without merging and **At risk** is the spend on open pull requests that are rotting. **By repo** and **By engineer** show where rotting work is concentrated, and **Where the last … days of PRs ended up** shows the split between merged, closed and still open for the selected period. The queue lists every pull request by cause; filter it by department, repository or engineer, switch to **AI-assisted only**, and dismiss or snooze a row you have dealt with. A ticket chip on a row filters the queue to that ticket, and **same ticket as #…** takes you to another open pull request on the same ticket. **Send the team digest** opens the digest, so you can send the queue to your team. ## Dismiss or snooze a pull request An admin can select **Dismiss** on a pull request that should leave the active queue. The pull request and its estimated dollars leave the queue totals. Choose a reason: **Not waste**, **Will close**, **Duplicate**, or **Other**. Select **Snooze** to set a return date instead. Choose **1 week**, **2 weeks**, **30 days**, or enter an **Until** date. The pull request and its estimated dollars leave the queue until that date, then return. Dates change at midnight UTC. Turn on **Show dismissed & snoozed** to find these pull requests again. The same switch also shows them in the engineer drawer. Select **Undo** on a dismissed or snoozed row to return it to the active queue. ### Engineers: where is work stalling, and with whom? **Every engineer** lists each person with a pull request in the period: merged, AI-assisted merges, open, aging, rotting, oldest inactive, closed without merge, abandon rate and AI spend. Switch between **People** and **Departments**, sort by **Rotting** or **Abandon rate** to find who needs help, and select a row to see that person's pull requests. A dash means spend could not be measured for that person. ### Cost: is waste going up or down? The chart shows wasted spend per day as bars, the at-risk backlog as a line, and **Cost per PR** below it. **Breakdown** splits wasted and at-risk spend by department, repository or engineer. **Realized savings** shows what changed after PR Health started flagging rotting pull requests. It counts how many flagged pull requests were later merged and how many were closed. It then puts the amount that was at risk when flagging began beside the amount at risk today, and shows **Cost per PR** then and now. Both at-risk amounts are priced at today's **Cost per PR**, so they differ only because the number of rotting pull requests changed. The **Cost per PR** then and now is a separate figure that shows how spend per pull request moved. The starting point is the first pull requests PR Health flagged, or the first ones flagged in the dates you choose. The line under the **Realized savings** title names that date. ### Vendors: what does a merged pull request cost with each one? PR Health prices every pull request at one organization-wide **Cost per PR**. To compare what a merged pull request costs with each AI vendor, open **Intelligence > Providers > Comparison**. With GitHub or [GitLab](/track-and-control-costs/analyze-ai-tooling-spend/gitlab-integration.md) connected, its unit economics table adds a **Cost/PR** column, or **Cost/MR** for GitLab: each vendor's spend divided by the merged pull requests its coding tools helped produce. A pull request counts toward a vendor when the assistant that helped write it leaves its attribution on a commit or in the pull request description. A pull request helped by tools from several vendors counts toward each of them, so the column does not add up to one total. [Comparison](/track-and-control-costs/monitor-infrastructure-costs.md) explains the rest of the view. ## Digest and alerts In **Settings > Configure digest**, choose a day, time, time zone and destinations (connected Slack channels or email addresses) for a weekly team digest. You can preview it and send a test before saving. Page filters do not change what the digest sends, and an admin must save changes. You can also turn on a weekday alert for pull requests that have started rotting. ## Limits * GitHub only. GitLab merge requests do not appear in PR Health. * **Wasted** counts every pull request closed without merging. PR Health does not show why a pull request was closed, so a cancelled change and one replaced by a newer pull request count the same way. * The ticket chip filters PR Health; it does not open the ticket in your issue tracker. * If the GitHub connection fails, the page stops at the last successful sync until someone with access reconnects it. * AI-assisted figures count pull requests that carry an assistant signature or match one of your detection patterns. Work from an assistant that leaves no signature is missed, and a broad custom pattern can also match text a person wrote, so keep custom patterns specific. --- # 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.revenium.io/track-and-control-costs/analyze-ai-tooling-spend/pr-health.md?ask=&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.