Using the dashboard

The dashboard is where you watch reviews happen, see workspace health at a glance, and read reviews without switching between pull requests.

The organization switcher

A dropdown at the top of every screen chooses which account you are looking at: All organizations, or one installation, listed as login (User) or login (Organization).

It is a single scope, not a per-page filter. Choosing one organization narrows all of these at once:

• Repositories — only that account's repositories;
• Reviews — only pull requests from that account, and the repository dropdown shrinks to match. Switching accounts clears the repository filter, since it may not belong to the new one, and returns you to page 1;
• Dashboard — only that installation;
• Settings and Members — the account those pages act on.

Your choice is remembered between visits, so the dashboard opens where you left it. If the organization you had chosen is no longer available — the app was uninstalled, or your access to it was removed — the switcher drops back to All organizations rather than staying on an account you can no longer see. The list refreshes as you move between screens, so a change — an installation that has gone away, or one a sync has just brought in — is reflected without a reload.

Beside the dropdown, a badge shows your role in the chosen organization; it is hidden under All organizations, where no single role applies. Choose Manage installations… from the switcher to open the GitHub App installation flow.

Developer and Builder mode

Under your username at the foot of the sidebar is a picker with two entries: Developer mode and Builder mode. It decides how much technical detail the dashboard shows you.

The choice is yours alone — it is stored against your account, follows you between devices, and changes nothing for your teammates. New accounts start in Developer mode, which is everything described on this page unless a section says otherwise.

Builder mode changes two screens:

Screen	In Builder mode
Dashboard home	The project status overview replaces the confidence gauge, the heatmap and the cards below them
Review detail	A plain-language summary replaces the file list and the individual findings

Everything else — Reviews, Repositories, Settings and Members — is the same in both.

Nothing about the mode reaches your pull requests: the review body, the inline comments and the check run are identical whichever mode you or anyone else is in.

The dashboard home

The sidebar groups the screens: Dashboard on its own, then Workspace — Reviews and Repositories — Organization — Settings and Members — and Support, which holds Help & Support. Reviews carries a badge with the number of reviews currently queued or running in the chosen organization, so work in flight is visible from any screen; it refreshes as you move between screens. In the header, a bell carries your unread support notifications.

In Developer mode the dashboard home summarizes workspace health for the selected organization scope; Builder mode shows project status instead. Its headline counts the reviews completed in the last seven days — or, when any review has failed, how many need attention instead.

The overview includes:

• a confidence gauge — a ring over your completed reviews split into High, Medium and Low, with the share that are high confidence in the middle; see Merge confidence;
• a 12-month activity heatmap of completed reviews by day — queued, running and failed reviews are not plotted. A day on which a review left a critical finding is shaded red rather than blue; hovering a day gives its completed reviews, their confidence split, and how many critical findings they left. Beside the grid: Busiest day, Median review time, and Current streak of consecutive active days. When any review has failed, a banner sits in this card — 2 reviews failed and can be re-run. — with View failures → beside it, opening the reviews list filtered to failures;
• a Repositories breakdown — the five repositories with the most reviews, each with its total reviews, how many are running, and how many critical findings its completed reviews left, with a confidence bar and percentage over that repository's own completed reviews. The link at the foot of the card counts the ones it left out — All repositories (7 more) →;
• Pending reviews — up to five pull requests whose latest review is queued or still running;
• GitHub connection information for connected installations.

The figures cover the whole selected organization, not just the reviews on screen. The dashboard refreshes when you switch organization. Use Sync From GitHub to re-read your organizations and their repositories from GitHub and refresh the dashboard data immediately. It also picks up any installation you have gained access to since signing in. The button is unavailable while your installations are still loading, and reports No GitHub installations to sync. if there are none to read.

The dashboard home in Builder mode

In Builder mode the home screen is about repositories rather than reviews. The confidence gauge, the activity heatmap, the repositories breakdown, pending reviews and GitHub connection are all gone, replaced by two cards:

• a ring over every repository in the chosen organization, the total in the middle, split four ways: Looks good, Needs attention, Scan or update — not scanned, out of date or failed — and Not enough info;
• Projects, every repository with its project status, its status branch, and when it was last scanned. Selecting one opens its project status page.

The headline above them reads the worst case first: 2 projects need attention., then 3 projects need a scan or update., then Some projects need more information., then All scanned projects look good. With no repositories at all it reads No projects connected yet.

Sync From GitHub works here too, and refreshes the project list.

Merge confidence

Each completed review carries a confidence rating — High, Medium or Low — set when the review is finished; see Merge confidence for how a review earns one. The gauge, the per-repository bars and the heatmap tooltip all read from it, and the percentage in the middle of the ring is the share of rated reviews that came back High.

Only completed reviews are rated; queued, running, failed and cancelled ones are left out of the split entirely. A completed review that produced no rating counts as Unrated — listed beside the gauge and excluded from the percentage, so a handful of unrated reviews lowers neither the High share nor the others.

Reviews completed before this rating existed are unrated too, and stay that way; they are not scored retrospectively.

Repositories

Every repository covered by an installation you can see. The search box matches anywhere in owner/name, and a counter above the list reads 12 of 40. The organization switcher scopes the list. When it looks out of date, Sync From GitHub on the dashboard home re-reads your installations.

Each row carries the repository's default branch, a Review on / Review off pill, and its project status — with scanned 3 days ago beside the status once a scan has succeeded. A dropdown next to the search box narrows the list to one status: All statuses, Needs attention, Needs scan, Not enough info or Looks good. Needs scan covers every repository without a current result — never scanned, still scanning, out of date, or a failed scan.

Selecting a repository opens its project status. The pull request count on the row opens that repository's reviews — a repository with none reads No pull requests — and Settings opens its settings page.

Reviews

A cross-repository list of the pull requests EasyMerge has seen — one row per pull request, ordered by the latest review's timestamp, newest first. Pull requests with no review yet use the pull request's own last-updated time instead. Each row shows the repository and PR number, the title, the author, the branches (head → base), and the state of that pull request's latest review: its status badge, how many files it has reviewed out of the ones eligible for review, and how many comments it left. Skipped files are counted in neither number, so a pull request with 15 files of which 3 are skipped reads 12/12 files once the review is done. Earlier reviews of the same pull request are not listed separately.

Each row links to the review detail, and the PR number links to the pull request on GitHub.

The organization switcher scopes the list first; three filters then narrow it further, and they combine:

Filter	Matches
Repository	One repository, or all of them
Review status	Pull requests whose latest review is in that state
Author	PR author login — substring, case-insensitive

The status options are Queued, Preparing…, Reviewing…, Completed, Failed and Cancelled — the same badges the rows show. See Review lifecycle.

Filters and the current page are kept in the URL, so a filtered list can be bookmarked or shared.

The list updates live: a review that moves from queued to running to completed changes in front of you, with no refresh. If the connection drops, it reconnects and catches up on what it missed.

Review detail

One pull request, one review, everything it produced:

• a header with the review status and the PR state; the PR number links out to the pull request on GitHub;
• a summary bar — 12 / 12 files reviewed, counted against the files eligible for review rather than every file in the pull request, then the total comment count, 3 skipped when any file was skipped, and how long the review took. A rated review ends the bar with Merge confidence and its level, for example High confidence; a review without a rating omits it;
• a file list down the left, in three groups: Files with issues at the top, expanded, then No issues and Skipped as compact rows below. A group with nothing in it is not shown. Each row gives the file name and its folder, a coloured dot for the most serious finding in it, how many issues it has, and its added and removed line counts; files with no findings show their status instead. Files the review has not resolved yet are left out until it does, so nothing is labelled "skipped" while it is still in flight;
• the selected file on the right: its findings, each with a severity badge, its line reference (line 44 or lines 44–45), the comment body, and the suggested replacement when there is one. Expanding a file in the left list lets you jump to one finding on its own. Selecting a skipped file names the pattern that matched it, or says why there was no diff.

Findings are shown against the diff with the file's real line numbers, and the commented range is marked.

Each finding also says whether it reached the pull request. posted on GitHub means it did; otherwise the label names what held it back:

Label	Meaning
not posted · severity filter	Its severity is not one of the levels you post
not posted · comment limit	The review had already posted its maximum
not posted · already raised by another run	Another review of the same commit posted this finding

This is where a finding goes when it is not on your pull request — it is kept and readable, never discarded.

When a run did not reach GitHub cleanly, a notice sits above the file list. Not posted to GitHub means Post review on GitHub was off for that run. Posting to GitHub not yet confirmed means EasyMerge is still checking with GitHub what arrived; it will not post anything twice, and the findings below are final either way. Posting to GitHub needs attention means it gave up checking — compare with the pull request before assuming anything was posted.

This view is live too — findings appear as they are produced, and each file moves into its group once it is done, whether or not it turned up anything. The counter climbs and the list fills in while the review is still running, so you can start reading before it finishes.

A Failed review still shows whatever it got to, with the error at the top — headed Review failed when nothing was reviewed, and Review didn't finish when there are findings below it, under the note The findings below come from the files that were reviewed before the run stopped. The pull request only carries a note pointing back here. If it stopped before any file was resolved the page says No results for this review. See When a review fails.

When there is no review yet, the page says so: No review yet for this PR. Push a commit or open the PR to trigger an AI review.

Review detail in Builder mode

Builder mode answers one question — can I merge this? — and drops the file list, the individual findings and the merged All runs tab. The per-commit tabs stay, so you can still move between runs.

At the top, a recommendation drawn from the review's merge confidence:

Recommendation	Score	Detail
Looks good to merge	8.0 and above	EasyMerge did not find a problem that should hold up this change.
Review before merging	above 5.0, below 8.0	One or more parts of this change deserve another look before merge.
Do not merge yet	5.0 and below	EasyMerge found an impact that should be addressed before merge.
No recommendation available	unrated	EasyMerge could not create a reliable Builder summary for this review.

The confidence level sits beside it, and the files-reviewed count on the right.

Under that, the review's findings are grouped by what they affect, most important first, each with:

• a plain-language title and how many findings it covers;
• a label — Fix before merging, Review this before merging or Optional improvement — taken from the most serious finding in the group;
• a paragraph on what it means for the product;
• Copy fix prompt, which puts a ready-to-paste instruction on your clipboard: the pull request, the outcome to aim for, and the findings behind the group with their files and line numbers. It confirms with Fix prompt copied.

A review that found nothing reads EasyMerge found no issues in the code changes it reviewed.

When the grouped summary could not be produced, the card reads Builder summary is unavailable. — Switch to Developer mode under your username to inspect the available technical findings. Nothing is lost: the findings are all there in Developer mode, and whatever was posted to the pull request was posted either way.

Settings and Members

Two screens, grouped under Organization in the sidebar, act on the organization chosen in the switcher:

• Settings — defaults applied to repositories as they are first synced;
• Members — everyone linked to that installation, with their role, 20 to a page.

Both are read-only for members and editable by admins, and neither applies to personal accounts. See Organization settings.

What you cannot do from the dashboard

Reviews are triggered by GitHub events only — opening or updating a pull request, or marking a draft ready for review, subject to the repository's trigger settings. There is no button to re-run a review; push a commit instead.

Replying to a finding is done on GitHub, in the pull request, like any other review comment.

You can, though, report a problem from here: Report a problem on a review detail page or a repository's settings page opens a support ticket with that repository — and that review — already filled in.