Understand findings

| A review run produces more than a list of comments: every finding carries labels that tell you what kind of remark it is and what fixing it would cost, the Overview sorts findings into what blocks a merge and what does not, and a merge readiness assessment sits beside the provider’s own mergeability state. This page covers how to read all of that, how to follow findings across successive review runs, and what to do when a panel is empty or out of date. Everything you read here belongs to the displayed snapshot — one review run against one head commit. Writing comments, resolving threads, and merging act on the live pull request instead, and are covered in Review and merge.

​

How a finding is labeled

A finding carries labels drawn from four independent closed vocabularies. They are four separate axes, not one severity ladder: a nitpick can be a security finding, and a critical finding can still be a poor trade-off to fix inside this pull request. Read them together rather than collapsing them into a single ranking.

​

Type — what kind of remark it is

​

Severity — how bad it is

Four ranked levels, highest first: critical, major, minor, trivial. Two more sit outside the ranking — info, which is guidance rather than a problem, and none, for a finding with no severity assigned.

​

Category — what area it concerns

Six areas: functional correctness, security and privacy, data integrity and integration, performance and scalability, stability and availability, and maintainability and code quality. Category tells you which lens a finding is looking through, which is what lets you weigh a security remark differently from a maintainability one on the same change. It is a label, not a filter — see below for what you can actually filter on.

​

Effort — what fixing it would cost

Effort is the axis most reviewers do not expect, and the one that changes what you do next. It pairs the work a fix takes against the benefit it returns, which lets you pull the quick wins into this pull request and push the heavy lifts into a follow-up without arguing about severity first.

​

The Overview and Needs your attention

The Overview is the view that shows pull-request status, the review summary, and attention items for the displayed snapshot. It is where you start when you want the shape of the change before reading any code. Switching between it and the other views is covered in Navigate a change.

​

Needs your attention

Needs your attention splits what the review produced into four sections, ordered by what stops you from merging: The ordering is a triage order, not a severity order. Blockers are the things that prevent a safe merge, so they are yours to clear now. Pending items are waiting on something outside your control — a check that has not finished, a review that has not been submitted, a provider state that has not settled — so they are worth checking on rather than working on. Advisory items are optional, and a change can ship with them outstanding.

​

Priority and severity bands

Overview items are ranked by a priority band from p1 (highest) through p4 (lowest), and carry a severity signal of critical, major, minor, or trivial. Both are ordinal: p1 outranks p2, and a critical signal outranks a major one. Use them to decide reading order within the Overview, not as a promise about what a specific item is — how a given item lands in a particular band is not something the ranking exposes.

​

Filter what you are shown

Findings can be filtered by severity, one bucket at a time: critical, major, minor, trivial. Alongside that you can hide resolved threads, hide outdated ones, hide comments from other bots, and collapse CodeRabbit’s findings entirely when you want to read the diff on its own. Separately, range summaries can be filtered by code complexity — low, medium, high — which is the control described in Read changes. There is no filter on category, type, or effort. Those three are labels you read on a finding, not axes you can narrow the list by. If you are signed in, these choices are saved to your account rather than to the pull request, so the filter set you settle on follows you to the next review.

​

Merge readiness

Merge readiness is CodeRabbit’s own assessment of the change, assembled from the review. It is a score placed in a band, a confidence figure for that band, and the individual concerns that drove it.

​

Why confidence sits beside the score

Each assessment carries a confidence of high, medium, or low. The confidence qualifies the claim rather than the change: a high-confidence “Ready” says the review had enough to go on and found nothing to stop you, while a low-confidence “Ready” says the assessment could not see enough to say much at all. Treat the second as an absence of evidence and lean on your own reading of the diff.

​

Drivers

A score is backed by drivers — the individual concerns behind it. Each driver has a severity of critical, major, or minor, and a status that says where it stands: A driver is open while the concern is still live, addressed once it has been dealt with, superseded when a later assessment replaced it, and not relevant when it does not apply to this snapshot. Statuses are what make readiness readable across successive review runs. A driver that moves from open to addressed tells you a push fixed something; one that goes superseded tells you a later assessment replaced the concern rather than that anyone acted on it. The two look similar in a summary and mean different things.

​

Merge readiness is not mergeability

Mergeability is a separate claim, and the two are easy to conflate. Mergeability describes the pull request itself — whether the provider will accept a merge right now: The mechanics of actually merging — the available merge actions, the merge queue, and why a merge is refused against a stale artifact — are covered in Review and merge.

​

Following the review across snapshots

Change Stack can compare review progress across snapshots and show you, finding by finding, whether it remains, was addressed, or was skipped. This is the answer to the question that makes re-reviews tedious everywhere else: after a push, you want to know what changed about the review, not re-read the whole thing. Instead of diffing two lists of comments by eye, you read the comparison and go straight to what is still open — and a finding marked skipped is visible as skipped, rather than silently missing from the newer run and mistaken for one that got fixed. You can follow review progress while a run is in flight, and when a completed run invalidates the snapshot you are looking at, Change Stack can refresh the displayed stack onto the new one. Each run resolves to one of five outcomes, all of which you can see and each of which means something different for what is on screen: A run ends as success, skipped, error, rate limited, or cancelled. Only a successful run produces findings. The other four are worth noticing before you read a quiet screen as good news: a run that was skipped, ended in error, was rate limited, or was cancelled has not told you the push cleared anything — it has told you nothing at all, and the previous snapshot is still the most recent complete picture.

​

When material is missing or stale

Blast Radius and Architecture Impact are generated separately from the review itself, and a snapshot can be missing one or both — either because generation is not switched on for your organization, or because it has not finished for that snapshot yet. An empty graph view is usually one of those, not a change with no impact. Change Stack offers repair actions for exactly these situations. Match the symptom to the request: None of these are instant. A request is queued and the material updates when the work finishes, so the page will not change under you the moment you click. Asking again while one is already running does not queue a second — you are told it is already in progress, or that nothing needed doing — and a request that fails leaves the previous material in place rather than blanking it. Prefer the narrowest request that fixes what you are looking at. A summary-only update leaves your snapshot in place, so links, chat threads, and pending review comments anchored to it stay valid; a full re-review produces a new snapshot and moves the ground under all of them.

​

Findings on the graph views

Blast Radius and Architecture Impact both carry findings linked to the displayed snapshot, so you can move from an affected system or dependency straight to what the review said about it. Blast Radius shows the code and dependency impact around the change; Architecture Impact shows affected systems, their relationships, and the deltas between them. These artifacts are defined by CodeRabbit Security — see Blast Radius and Architecture review for what they contain and how they are produced. Change Stack displays them for the snapshot you are on and links their findings back into the change.

​

What’s next