Reviewer status is in the Reviewers box on the right side of the pull request page. A green check means they approved. A red icon means they asked for changes. A speech bubble means they left comments without a verdict. A small orange dot means you're still waiting. To check more than one PR without opening a tab for each, use search qualifiers like review:changes_requested or run gh pr status in your terminal.
TL;DR
- The sidebar shows each reviewer's latest state. The merge box shows whether the PR as a whole meets the branch rules. Those two can disagree.
review-requested:@meonly lists reviews you haven't done yet. Once you submit one, the PR drops out of that search.gh pr statusgives you the review decision for all your PRs in one command.- A comment-only review never counts as an approval, however nice the comments are.
What do the reviewer icons on a pull request mean?
Open any PR and look at the Reviewers section in the sidebar. Every requested reviewer, plus anyone who reviewed without being asked, gets a row with an icon:
| Icon | What it means | Counts toward merge? |
|---|---|---|
| Orange dot | Review requested, nothing submitted yet | No |
| Green check | Approved | Yes, if they have write access |
| Red file icon | Changes requested | Blocks merge on protected branches until resolved or dismissed |
| Speech bubble | Commented, no approve or reject | No |
GitHub has three review types: Comment, Approve and Request changes. The icon reflects the reviewer's most recent one. If someone requested changes and later approved, you'll see the check.
The circular-arrows icon next to a reviewer's name is Re-request review. Click it after you've addressed their feedback. It puts them back in the pending state and sends them a notification. That's a lot more polite than pinging them in Slack with "bump".
Why the merge box can disagree with the sidebar
This one confuses people all the time. The sidebar shows two green checks, and the merge box at the bottom still says Review required. Common reasons:
- Required approvals count. The branch protection rule might want two approvals from people with write access. An approval from someone without write access shows a check, but it doesn't count.
- Code owners. If the repo has a
CODEOWNERSfile and the rule requires code owner review, an approval from anyone else won't satisfy it. The code owner for the files you touched has to approve. - Stale approvals. With "Dismiss stale pull request approvals when new commits are pushed" turned on, your fixup commit just wiped every approval. The reviewers didn't change their minds. The rule did that.
- An outstanding change request. One red icon blocks the merge even if three other people approved, until that reviewer approves or someone with permission dismisses the review.
GitHub's docs on protected branches cover each of these settings. If a PR is stuck and you can't tell why, check them before blaming your reviewers.
How do I check reviewer status across all my PRs?
Opening every PR to read the sidebar falls apart around the third repo. GitHub search has qualifiers just for review state, and they work on github.com/pulls or in the main search bar. The full list is in the issues and pull requests search docs. These are the ones I use:
is:open is:pr author:@me review:changes_requested
is:open is:pr author:@me review:approved
is:open is:pr author:@me review:required
is:open is:pr review-requested:@me
is:open is:pr user-review-requested:@me
is:open is:pr reviewed-by:@me -author:@me
is:open is:pr team-review-requested:my-org/backend
A few things that aren't obvious:
review:requiredandreview:approvedfollow the merge rules, not the sidebar icons. Soreview:approvedmeans the PR meets the approval requirements. It doesn't mean one person clicked approve somewhere.review-requested:@meincludes requests made to teams you're on.user-review-requested:@meonly shows the ones where someone picked you by name. If you're on a team that CODEOWNERS adds to every PR, the second one cuts the noise a lot.- Once you submit a review, you're no longer "requested", so the PR vanishes from
review-requested:@me. To find PRs you reviewed that are still open, usereviewed-by:@me. - Each of these searches is one tab you can bookmark. That's better than fourteen tabs, but it's still four or five bookmarks.
The Review requests tab on github.com/pulls is basically review-requested:@me with a nicer face.
Checking reviewer status from the terminal
If you already live in the terminal, the GitHub CLI does a decent job here. Something like this:
# Your PRs, PRs waiting on you, and the current branch's PR, with review decisions
gh pr status
# Everything waiting on your review in the current repo
gh pr list --search "review-requested:@me"
# The details for one PR
gh pr view 123 --json reviewDecision,reviewRequests,latestReviews
gh pr status labels each PR with things like Review required, Changes requested or Approved. That's the same decision the merge box shows. The --json output is the useful bit for scripts. reviewDecision is the overall verdict. reviewRequests lists who's still pending. latestReviews gives you each person's most recent state. If the repo doesn't require reviews at all, reviewDecision can come back empty, so don't build a script that assumes it's always filled in.
The catch: gh pr status and gh pr list look at one repo by default. For several repos, either loop over them in a small shell script or go back to the web search, which covers everything you can access.
Why this is still annoying
None of this is hard. It's just scattered. The individual state is in the sidebar, the overall decision is in the merge box, the cross-repo view is in search, and the terminal view is per repo. Then GitHub emails you every time any of it changes, which is how you end up with an inbox like the one in too many GitHub notification emails.
In practice, most of us skip the bookmarked searches and just leave the PRs open. One tab per PR, refreshed now and then to see if the dot turned green. We've written about why the tab pile happens and how to get out of it. Short version: tabs are a bad status dashboard.
Where PRFlow fits
PRFlow is a Chrome side panel we built because of exactly this. It lists your open PRs across repos with their review state (pending, changes requested and so on), plus labels, comment counts and diff size. It stays docked next to whatever tab you're on, so checking status doesn't mean switching away from your work.
It also has filter groups that match the searches above:
- Needs my review: the same idea as
review-requested:@me - Created by me: your PRs and where each one stands
- Reviewed but not merged: PRs you've already looked at that are still open, which is the
reviewed-by:@mecase people forget about
What it doesn't do: it doesn't change your branch protection, it doesn't approve or dismiss reviews for you, and it doesn't pester your reviewers. Re-requesting a review, resolving threads and merging still happen on GitHub. PRFlow saves you from opening a tab just to learn that nothing changed. If you're comparing options, there's a broader roundup of Chrome extensions for code review.
Habits that make reviewer status easier to read
Tooling only helps so much. These habits keep the signal clean:
- Re-request after pushing fixes. If you don't, the reviewer's old "changes requested" stays up and nobody knows it's their turn. The re-request button is the clearest "ready for you" signal GitHub has.
- Approve when you mean approve. A comment-only review that says "LGTM" leaves the PR blocked, and the author has to work out what you meant. If it's good, click Approve. If it isn't, request changes.
- Use draft PRs for work in progress. Opening as a draft and marking it ready later stops reviewers getting requested before there's anything worth reviewing. GitHub doesn't send CODEOWNERS review requests until the draft is marked ready.
- Keep requested reviewers few. Three people requested "just in case" usually means nobody feels responsible. One or two names, chosen on purpose, get reviewed faster.
- Sort out stale-approval expectations as a team. If the repo dismisses approvals on every push, say so in the contributing guide. Then nobody's confused when their green checks disappear after a typo fix.
For how all of this fits into a full review cycle, from request through merge, see the GitHub PR review workflow guide. More posts are under the code review tag.