The HeyDeer Review check
HeyDeer reports each review in a GitHub check named HeyDeer Review. Learn what its result means and how to make it block merging.
What the check shows
The check sits on the commit HeyDeer reviewed. It shows the review’s progress, then completes with one of the conclusions below. Its Details link opens the review in HeyDeer.
While Autopilot works on a PR, the check stays in progress until Autopilot stops and HeyDeer publishes its review.
By default, findings don’t fail the check. To block merging until they’re fixed or declined, turn on Fail the check when issues are found and require the check.
The summary starts with the number of findings, open earlier concerns and failed repository checks. For a follow-up review, it says whether HeyDeer reviewed only the changes since its previous review.
Below it, the check shows the complete review: review notes, every finding, concerns declined in discussion, and the approval decision when Automatic approval is on. See Reading a review.
Require the check before merging
- Let HeyDeer review at least one pull request in the repository, so the check exists.
- In GitHub, open the branch protection rule or ruleset for your base branch and turn on required status checks.
- Add HeyDeer Review and select HeyDeer as its source.
- In HeyDeer, turn on Fail the check when issues are found in Workspace settings → Review rules → Publish results, or in a repository’s Review rules.
GitHub treats Success, Neutral and Skipped as passing, and Failure, Action required, Timed out and Cancelled as blocking.
Once HeyDeer publishes checks in a repository, every pull request update gets a check result, so a required check never waits forever.
In a Manual only repository, HeyDeer publishes no check until its first review there. See Automatic reviews.
If no check appears, see Troubleshooting.
Fail the check when issues are found
This setting is off by default, so a completed review passes even when it reports findings.
With it on, the check fails for findings within the feedback scope, including findings linked to existing conversations, and for open or unconfirmed earlier concerns. Concerns someone with write access declined don’t count. See Earlier concerns.
A review with review notes fails too. Some commits that weren’t reviewed automatically show Action required instead of Skipped; see Conclusions.
Conclusions
| Conclusion | Title | When |
|---|---|---|
| Success | Review completed — no issues found / Review completed with findings / Earlier concerns need confirmation / Review completed with warnings | The review is complete and nothing needs clarification. With Fail the check when issues are found off, this includes reviews with findings or earlier concerns. |
| Neutral | Review incomplete / Review completed with findings / Review needs clarification | A question needs clarification, whatever the setting, or the review has review notes and Fail the check when issues are found is off. |
| Failure | Review found issues that need attention / Earlier concerns need confirmation / Review incomplete / Review could not run / Review failed | With Fail the check when issues are found on: findings, earlier concerns or review notes. Whatever the setting: a repository check didn’t run, an earlier concern wasn’t rechecked, or HeyDeer couldn’t start or finish the review. |
| Timed out | Review timed out | The review ran out of time. |
| Cancelled | Review canceled / Review superseded | The review was canceled, or its result no longer applies because the base branch changed or no open PR has this commit as its latest commit. |
| Skipped | Review skipped / No reviewable files | Your automatic review filters exclude the pull request (by default, drafts, PRs from forks and dependency updates), or every changed file is outside the review scope. The check is also skipped when HeyDeer stops an automatic review because the PR changed. |
| Skipped or Action required | Review skipped / Review required | No automatic review ran because of Manual only, Once per PR, a pause on the PR, or Maximum automatic reviews per PR. Or the workspace is out of credits or reached its usage limit, or the repository is linked to Free credits in another workspace. With Fail the check when issues are found on, this is Action required, which blocks merging. |
When HeyDeer doesn’t review a commit automatically, the title names why, for example that the pull request reached Maximum automatic reviews per PR.
When a commit wasn’t reviewed or the review didn’t finish, the summary says what to do next, usually to comment @heydeer review. See also Troubleshooting.
Request a review from the check
Re-run, Re-run all and the Review this revision button each request a review of the check’s commit, as if you commented @heydeer review. Review this revision appears when a review is the next step. See PR comment commands.
If HeyDeer can’t accept the request, the check stays as it is. Comment @heydeer review to see why.
Merge queues
In a merge queue, the check confirms that each queued pull request meets its review requirements, without reviewing the combined code or using credits. Your CI should still check the merge group.
When several open PRs share a commit
Open PRs with the same latest commit share one check, which passes only when every PR’s review allows merging. Its summary links to each PR’s full report.
A shared check has no Review this revision button; request a review on the specific PR instead.