Review Usage dashboard

Read the Review Usage dashboard: review events, rate-limit impact, per-developer adaptive limits, and the Review Log behind them.

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.

For what draws down your allowance in the first place, how it refills, and how to spend fewer reviews, see Review rate limits.

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.

My usage showing key metrics, daily activity, and the current refill rate

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.

Hovering a day shows the refill rate in force, the rolling attempt count, and the outcome split for that day

The chart always renders exactly 7 or 30 calendar days ending today, while the cards above it cover a rolling window measured backwards from right now. The two do not have the same edges, so the bars are not expected to add up to the card totals.

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.

Review Log grouped by pull request, showing review events and findings per PR

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.

Review Log in Timeline mode, one row per review event

Reading a single pull request

Expanding a pull request shows every review event it produced.

A pull request that produced three review events in twenty minutes, two of them over the hourly limit

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.

Initial review and Incremental review are inferred from the order of the events on screen, and Hourly usage is reconstructed from the events loaded into the page. Both are close enough to read patterns from and are not exact accounting.

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.

Team usage with organization totals and per-developer review activity

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.

What you see	What it means
Review events	Review decisions, not completed reviews. A blocked attempt is a decision
Rate limited	Encounters with the included limit, both blocked and continued
Within limit	Reviews that were allowed to run, including the rare case where CodeRabbit allowed a review because limit data was briefly unavailable
Current adaptive limit	The most recent limit observed in your review history, which can lag the live limit by a few minutes
Active users	Developers with review activity in the selected window, not seats or organization members
Findings	Shown only when each review event maps to exactly one review run. The column is hidden rather than shown approximately

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.

Counter	Where you see it	What it counts
Review events	The Review events card and the Review Log	Every review decision, including attempts that were blocked and attempts that continued with credits
Included reviews	Your plan’s hourly allowance	Only reviews admitted within the included limit. Blocked attempts and credit continuations do not draw it down
Rolling 7-day activity	The adaptive limit and the Fair Usage Limits Policy	Only included reviews. Blocked attempts and credit continuations do not raise it

What’s next

Review rate limits

Learn what counts as a review event, how your allowance refills, and the patterns that exhaust it fastest

Automatic review controls

Pause incremental reviews, opt in by label, and exclude work-in-progress branches so reviews run when you want them

Plans and pricing

Compare per-developer review limits, file limits, and chat limits across plans