> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coderabbit.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Review Usage dashboard
> Read the Review Usage dashboard: review events, rate-limit impact, per-developer adaptive limits, and the Review Log behind them.
export const DeploymentBadge = ({variant = "cloud-only", tip, title, cta = "Learn more", href = "/self-hosted/overview", disabled = false}) => {
const isCloudOnly = variant === "cloud-only";
const defaultTitle = isCloudOnly ? "Cloud Only" : "Self-Hosted Only";
const defaultTip = isCloudOnly ? "This feature is available on CodeRabbit Cloud only. It is not available on self-hosted CodeRabbit deployments." : "This feature is available on self-hosted CodeRabbit deployments only. It is not available on CodeRabbit Cloud.";
return
{title || defaultTitle}
;
};
export const EssentialsPlanBadge = ({tip = "This feature is available on Essentials (formerly Pro), Team (formerly Pro+), Advanced, and Enterprise. Please refer to our pricing page for more information about our plans and features.", title = "Essentials Plan", cta = "Read more", href = "https://coderabbit.ai/pricing", disabled = false}) => {
return
{title}
;
};
**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](/cli/index) and [IDE extensions](/ide/index) 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](https://app.coderabbit.ai/dashboard/review-capacity)** 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](/management/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](#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](/management/usage-based-addon) 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](/management/rate-limits#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.
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.
**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](/management/rate-limits#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.
**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](/management/rate-limits#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](https://app.coderabbit.ai/settings/subscription).
| 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](/management/rate-limits#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
Learn what counts as a review event, how your allowance refills, and the patterns that exhaust it fastest
Pause incremental reviews, opt in by label, and exclude work-in-progress branches so reviews run when you want them
Compare per-developer review limits, file limits, and chat limits across plans