Review Usage dashboard

Review Usage shows review events, rate-limit impact, and review limits per developer and for the whole organization. Use it to answer the question that usually follows an unexpected rate limit: where did the reviews go, and which pull requests spent them. Review Usage covers pull request reviews on Git platforms for developers on the Essentials, Team, Advanced, and Enterprise plans. Reviews from the CLI and IDE extensions draw on separate allowances and do not appear here, and neither do Free, trial, or open-source reviews. Viewing the page requires the metrics:read permission. Open it at Analytics → Review Usage in the CodeRabbit dashboard.

​

My usage

The My usage tab shows your own review activity for the last 7 or 30 days. Administrators can open the same view for any developer from Team usage.

​

Key metrics

Review events — every review run in the selected window. Rate limited — runs that reached your included limit, split into N blocked · M continued. This card is not a count of reviews that failed to run. A continued review did run; it was billed through the usage-based add-on instead of drawing from your included allowance. Pull Requests — distinct pull requests with at least one review event, with review events per pull request underneath. A ratio well above 1.0 is the signal that incremental reviews, not new work, are consuming the allowance.

​

Daily Activity

Each bar is one calendar day in your local time zone, split by outcome:

• Gray, Within limit — the review ran against your included allowance.
• Red, Rate limited — the review did not run on that attempt.
• Green, Continued with credits — the review exceeded the included limit and ran through credits or usage-based billing.

A thin white line across the chart traces your adaptive limit over the same period. When sustained activity moves you into a lower bucket under the Fair Usage Limits Policy, the line steps down, and you can see the drop line up with the days that caused it. Reducing activity lets it recover. Above the chart, Current refill rate shows the most recent limit CodeRabbit observed for you, along with the rolling attempt count behind it and the time that snapshot was taken. Hovering a bar breaks that day down into review events, blocked attempts, and continuations. Select any non-empty bar to filter the Review Log to that day; select it again to clear the filter.

​

Limit history

Limit history lists the points where your observed limit changed, labeling each as an increase, a decrease, or the first observation in the window. When the limit held steady, it says so in one line rather than listing every event. The section stays collapsed by default and shows the eight most recent changes. Enterprise developers do not have an adaptive limit, so the current refill rate panel and Limit history do not appear for them.

​

Review Log

The Review Log lists the individual decisions behind the numbers above. Both views share a search box, an Outcome filter for Within limit, Rate limited, and Continued with credits, and the day filter set by the chart. Pull requests groups events by pull request, most recent first, and summarizes each group as review events, incremental reviews, findings, and rate-limit outcomes. Sort by Recent activity, Most review events, or Most files reviewed to find the pull requests that consumed the most. Timeline drops the grouping and lists every event newest first, with the outcome, review kind, files reviewed, and the adaptive limit in force at the time.

​

Reading a single pull request

Expanding a pull request shows every review event it produced. Since previous and Hourly usage are the two columns worth reading closely. CodeRabbit highlights a gap of five minutes or less, and highlights hourly usage once you are at or above your limit. In the example above, review #2 arrives five minutes after review #1 and pushes usage to 6/5 — the branch received a second push before the first review had finished. A cluster of three or more events with five minutes or less between each is flagged on the row, because those reviews were most likely superseded before they produced feedback. See Superseded reviews for what causes the pattern and how to avoid it.

​

Team usage

The Team usage tab aggregates the same data across your organization. Users affected counts developers who hit their included limit at least once, as a share of developers with any review activity in the window. Review Usage by User ranks developers by rate-limit impact, showing review events, blocked and continued counts, the current adaptive limit, and last activity. Select any row to open that developer’s full history. The daily chart here has no adaptive-limit line, because adaptive limits apply per developer rather than to the organization as a whole. When Users affected reads 1 of 1 or 1 of 20 and a single row holds nearly all of the review events, the organization’s reviews are landing on one bot or service account rather than spreading across seats. See One identity for every pull request. When more than half of your active developers, or more than half of your review events, hit the included limit, a callout appears above both tabs offering to enable usage-based reviews or raise your monthly cap. It is visible to administrators who can manage the subscription.

​

What the numbers do and do not mean

Review Usage is operational telemetry. It is precise enough to diagnose a consumption pattern and is not a billing ledger — for billed usage, see Subscription and Billing. Review Usage loads the 100 most recent events, up to 500 for a single selected day, and up to 500 developers in Team usage. When a limit applies, the page says so on screen.

​

Three counters that are easy to confuse

The dashboard, your hourly allowance, and the Fair Usage Limits Policy each count something slightly different. A blocked push is the clearest example: it appears on the dashboard, but it costs you nothing and does not push you toward a lower adaptive limit.

​

What’s next