Troubleshooting

No review appears on a pull request

Work down this list:

1. Is the app installed on that repository? GitHub → Settings → Applications → EasyMerge → Configure. A repository added to an organization after an "only select repositories" install is not covered until you add it.
2. Are reviews enabled? Check the toggle on the repository's settings page.
3. Is the pull request still a draft? Drafts are skipped by default. Mark it ready for review, or turn off Skip draft pull requests.
4. Is the event one you trigger on? opened and synchronize are on by default; reopened is not. See Trigger on PR events.
5. Did the PR event actually happen? Editing a title or description does not trigger a review. Push a commit.
6. Is the check run there? If EasyMerge Review shows as queued or in progress, the review is running — large pull requests take longer. If it says Review skipped, its summary names the reason.
7. Was the PR opened while reviews were off? Turning them back on does not review it retroactively. Push a commit.
8. Has that commit already been reviewed? A commit is reviewed once. Reopening a pull request you have not pushed to produces nothing new — push a commit.
9. Is Post review on GitHub off? Then nothing reaches the pull request by design, not even a check run. Open the repository in the dashboard — the review and its findings are there.

The repository is missing from the dashboard

Press Sync From GitHub on the dashboard home. If it still does not appear, the installation does not cover it — add it on GitHub, then sync again. A repository that was removed from the installation comes back with its earlier reviews and findings intact.

Check the organization switcher too: with a single organization selected you only see that account's repositories.

If the page says No GitHub App installation found, the app is not installed anywhere you can see; go through Install the GitHub App.

An organization is missing from the switcher

If you were given access after you signed in, reload the dashboard — EasyMerge re-checks your access with GitHub on each visit — or press Sync From GitHub, which does the same check straight away. Signing out and back in is not needed.

If it still does not appear, GitHub does not report you as having access to that installation; confirm on GitHub that your account can see it.

A teammate cannot see anything

They must sign in to EasyMerge at least once with their own GitHub account. Access is derived from GitHub per user, not shared across an organization.

If they signed in before being given access, a reload is enough — access is re-checked with GitHub each visit, so they do not need to sign out and back in.

If they signed in and still see nothing, confirm on GitHub that their account has access to the repositories in the installation. A member with access to none of them sees empty Reviews and Dashboard pages rather than an error, so an empty dashboard is what no access looks like.

The settings page is read-only

Expected for everyone except the person who installed the app on that account. The View only badge means exactly that. Ask them to make the change.

A file was not reviewed

Open the review detail and select the file in the Skipped group. Its label and the pane on the right say what happened:

Label	Pane says	Meaning
excluded	Excluded by pattern: <pattern>	That pattern is in the repository's exclude list
too large	No diff available — the file is binary or too large to review.	GitHub provided no diff
skipped	max_files_exceeded	The pull request had more reviewable files than Max files per review allows

The pane names the exact pattern, and every pattern is yours to remove — including the ones the repository started with. Delete it on the settings page and the file is reviewed from the next review onwards.

A file past the cap is the one you can act on without removing anything: excluding generated code and fixtures frees room for the files you want read, and splitting the pull request works too.

The review says Failed

Usually a temporary outage rather than anything about your code. No inline comments were posted; the pull request carries one Review could not be completed status comment instead, linking back to the dashboard.

The detail page shows how far it got — Review failed with No results for this review. if nothing was read, or Review didn't finish with partial findings if some files were. Those findings are not posted to the pull request.

Push a commit to run a fresh review. If it fails repeatedly on one pull request, note the PR link when reporting it.

The review says Cancelled

The page names the reason under the heading. Most often you pushed another commit — A newer commit replaced this review. — and the review of the new commit is the one to watch. Otherwise the pull request was closed or merged mid-review, which stops comments arriving on a PR you have already merged, or the branch you are merging into moved while the diff was being read, in which case push a commit to review again.

Push a commit after reopening to get a fresh review — reopening alone only triggers one if you have ticked reopened under Trigger on PR events.

The review has a summary but no inline comments

Either every finding was checked against the whole pull request and none held up, or your settings held them all back. The body tells you which: ◌ Findings kept in EasyMerge means there were findings and the severity or comment-limit settings kept them off the pull request. Open the review detail — each one is labelled with why it stayed there.

If the findings you are missing are all minor, info is the likely cause: it is off by default under Comment severities.

Fewer comments than the last review on the same code

Expected, and not a sign of anything wrong. Each push is reviewed from scratch and findings are judged against the pull request as it then stands, so one posted before may be dropped this time — or scored at a different severity.

Nothing happened when I reopened the pull request

A commit is reviewed once. If its review already completed, reopening produces nothing new. Push a commit.

If the previous review failed or was cancelled, reopening does start a new one — provided reopened is ticked under Trigger on PR events.

Reviews are slower than expected

Time scales with the size of the diff. Excluding generated code and splitting large branches into smaller pull requests both help — see Large pull requests.

A project status scan failed

The page keeps the last successful result and heads it The latest scan failed. The message beside it names the cause: a branch that no longer exists on GitHub needs a new status branch; the rest — a refused request from GitHub, a timeout, an unexpected failure — are worth one more Scan again before reporting. See When a scan fails.

No supported project files were found on this branch. is not a fault: the branch holds none of the files a light scan reads.

The dashboard is missing the gauge and the heatmap

You are in Builder mode. The picker under your username in the sidebar switches back to Developer mode. See Developer and Builder mode.

The dashboard stops updating live

It reconnects on its own and catches up on what it missed. If it does not, reload the page. With many tabs open you can hit the limit of eight live connections per user — close a few.

Reporting a problem

Open a support ticket from the dashboard: Help & Support in the sidebar, then New ticket. From a review detail page or a repository's settings page, Report a problem does the same thing and fills in the repository — and the review you were looking at — for you.

Have these ready:

• the pull request URL,
• the review status shown in the dashboard,
• what you expected instead,
• roughly when it happened.

Screenshots and log files can be attached to the ticket; keep passwords and access tokens out of them. Replies arrive on the ticket, and the bell in the dashboard header tells you when one lands.