Remarks, gathered into one review
The number in the gutter turns into a plus as the pointer passes it. What you write is kept until you send the review, so the author is told once rather than five times.
v2.9 · native macOS · MIT licensed
Know what GitHub is
Know what GitHub is
waiting on.
A menu bar app that keeps the counts in sight — and lets you read every file's patch, write the remarks, approve and merge without opening a browser.
$brew install --cask sidler/tap/githubmonitor
Free and MIT licensed · no account anywhere but GitHub
The counts live in the menu bar. Reviews requested, your own pull requests, unread mentions.
Review without leaving it
The whole review happens in the app.
A diff read three words at a time in a 400-point pane is not read. Clicking a file opens every file's patch in one scrolling overlay, with a tree to jump by.
A review in a window of its own
Not a card over the list: a window, with the code running to the edges. Several reviews can be open at once as tabs, and a tab shows a dot while it holds remarks you have not sent.
- The file tree down one side, the pull request's details down the other — ⌥⌘I, and the edge can be dragged
- All the files at once, or one at a time with ⌥← and ⌥→
- The words that actually changed are drawn bold — indentation too
- The code around a hunk is fetched from GitHub on a press; the file header has a button for the whole file
- The tree marks the files that hold remarks, and your own unsent ones in purple
Two columns, lined up where it means something
One column is what a patch is and fits anywhere. Two columns put the old file beside the new one, which is what you want when a line was edited rather than replaced.
- A removal is paired with the addition that answers it only where the two are recognisably the same line
- The rest get a row each, rather than being paired by position with whatever was left over
Write the remark, don't type the markdown
Buttons above the box for bold, italic, code, links, quotes and lists, with ⌘B, ⌘I, ⌘E and ⌘K — and a preview of exactly what will be sent. It is markdown that goes to GitHub, so it is markdown the box shows.
- Conventional comment labels over the box: issue, suggestion, praise and nine more, with blocking, non-blocking and if-minor
- The badge is written the way the convention writes it, in the colours the standard uses
- Several remarks half-written at once, each on its own line — they survive turning to another file, and quitting
- Closing a review with words still in a box asks what should become of them
Approvals bound to a commit
The approval belongs to the commit whose diff was on screen. If somebody pushed while you were reading, it is refused rather than applied to code you did not see.
Merging, with the reason given
Only the ways that repository allows. What stands in the way is said rather than greyed out: a conflict, checks that have not passed, a review that was asked for and is missing.
@ offers the people it reaches
Not the members of the repository and not whoever has touched it, but GitHub's own answer to who a mention there actually notifies. Driven entirely by the keyboard.
Conversations where they were written
Each one stands at its line, settled ones shut, with the few lines of code it was about where GitHub no longer gives it a place.
Commits, pictures, and what it links to
A pull request's commits with each one's own checks. Pictures in a description are drawn, private attachments included. A panel summarises the issue it closes without leaving the diff.
Know what is waiting
Lists you define, in GitHub's own syntax.
Each list is a title and one or more GitHub searches, shown as pull requests or
as issues. @me is you, and GitHub resolves team membership itself.
Rows that answer at a glance
Review decision, check results, whether the pull request still merges into its base branch, how far the review has got — and how long it has been waiting on you.
- The date turns orange and then red once your own review has been outstanding too long
- Press a symbol in the legend, or a label on a row, to see only those rows
- Sorting and grouping per list; each list remembers its own choices
- A detail pane with the branch, the files, every check and each reviewer
A list is a title and a search
Write it in GitHub's own syntax, one search per line, results merged. Each list says what it shows, which symbol it carries, and where it appears — the window, the popover, the menu bar, or any of the three.
- Start from a preset, or from nothing
- Drag to reorder: the sidebar, the popover and the menu bar all follow that order
- Written to a file and read back, with a confirmation naming what an import would replace
- Sorting, grouping and whether drafts show are remembered per list
What an issue is part of, and what is under it
GitHub's own relation, not a number read out of prose. An epic lists its children with how far through them it is; the far commoner case — an issue that is somebody's sub-task — says what it belongs to.
- "6 of 11 done" and a bar, each child with its state and its type
- The count is on the row too, so a list of epics can be read for who is nearly done without opening any of them
- Clicking a child previews it in the same panel the linked pull requests open
- Long lists fold after the first twelve, and say how many are not shown
Labels, set from the pane
The ones an item carries are shown and can be set and cleared against the repository's own list — searchable where it runs to hundreds, with the ones already on it first.
- Works on pull requests and on issues, from the same pane
- Press a label on a row to see only the rows carrying it
- What the list is narrowed to is named at the top, and can be cleared from either end
The quick look, under the menu bar
The counts live in the menu bar and the popover gives the short overview — the lists you marked for it, and the unread mentions from the notifications API.
- All counts, a single total, or zeros hidden
- Mentions filtered by the notification reasons you care about
- No Dock icon while it is only watching
Analysis
Who is carrying what, and how you review.
Three views, all drawn from the same data the lists use.
Workload, Trends, My Trends
Workload is one repository's open pull requests per author, ready and draft as separate segments, plus who does the reviewing and how long the rest of the team waits. Trends follows a repository over time. My Trends is about you.
- How long reviews wait on you, and how fast you answer
- Who you review with, and who comments on your work
- How many pull requests stand open, and how many are still drafts
- Over 30 days, 90 days or 12 months
All four Workload views are one table
Named columns, a bar in the row, and a footer under each saying how its numbers are counted — so a ranking can be argued with rather than only looked at.
- Open pull requests per author, ready and draft as separate segments
- Who does the reviewing, and how long the rest of the team waits for an answer
- The mean, the slow tail, and the requests that went unanswered
- A person's own pull requests are left out of what they reviewed
Stay out of the way
It watches. It does not ask for anything.
No account anywhere but GitHub. The token lives in the keychain, and nothing
else is contacted — api.github.com and avatars.githubusercontent.com, that is all.
The token stays in the keychain
A classic personal access token with repo, notifications and read:org. Nothing is sent anywhere else, and nothing is written to disk that would outlive the question it answers.
The hourly budget, in plain sight
Settings report what GitHub actually charged for the last refresh and what that comes to over an hour — GitHub's own figure, not an estimate. Polling stops before the allowance does.
Every request, written down
When, which call, the status, how long it took, what the allowance had left — and where something went wrong, what GitHub actually said. The successes too, because a log holding only failures cannot say whether anything was working in between.
Built for this Mac
Native SwiftUI on macOS 26, using the system's own glass materials rather than reproducing them. No Electron, no Dock icon, no tray of background services.
Install
Two lines and a consent.
Homebrew asks you to trust a tap that is not its own before it will run anything from it — the middle line is that consent, and it is needed once.
zsh — githubmonitor
$ brew tap sidler/tap $ brew trust --cask sidler/tap/githubmonitor $ brew install --cask githubmonitor # or take the zip from the latest release
The app has no Dock icon while it is only watching — look for it in the menu bar. Opening the window gives it one, and closing the window takes it away again.
- ✓macOS 26 or later. The app uses the system's own glass materials rather than reproducing them.
- ✓A classic personal access token. Fine-grained tokens do not reliably cover the notifications API.
- ✓Nothing else. No server, no sign-up, no subscription. MIT licensed, and the source is all there.
Setting up the token
Generate it
At github.com/settings/tokens → Generate new token (classic), with an expiry you are comfortable with.
Tick three scopes
repo for pull requests including private ones, notifications for the mention threads, read:org so the app can offer your teams.
Paste it in
Under Settings → Account. It goes straight to the keychain. When it expires the menu bar icon says so.
Put the counts where you can see them.
Free, open source, and it asks for nothing but a token.
$brew install --cask sidler/tap/githubmonitor