Icons, colours and checks: what every GitHub state means

In the repository's Pull requests list, every row starts with an icon: the pull request status. As of 2026 there are four, and each has its own shape as well as a colour:

• Open: the pull request icon, two dots joined by lines with an arrow. Green. Waiting for review or merge.
• Draft: the same icon with a dashed line. Grey. Work in progress; it can't be merged.
• Merged: two lines joining into one. Purple. The changes are in the base branch.
• Closed: the pull request icon with a small cross. Red. Shut without merging; nothing reached the code.

The small mark next to each title is something else: the combined result of its checks.

By default the list shows only Open. Merged and closed pull requests sit together under Closed, right next to it. Some rows come from bots: Dependabot, for example, opens a pull request whenever a library the site uses gets a new version. In a terminal, gh pr list --state merged lists only the merged ones.

The Closed view of the pull request list is easy to misread. It holds every pull request that is no longer open, and that means two very different endings:

• Merged: the merge icon, two lines joining. The changes are in the base branch. At CatChow, a merge into main is on the site within minutes.
• Closed without merging: the pull request icon with a cross. Someone shut it, and nothing from it reached the code. An experiment that didn't pan out, a duplicate, or work replaced by a better pull request.

So “it's under Closed” tells you only that the pull request is finished, not how it finished. Read the icon on each row, not the tab name.

For a PM this matters whenever you report. “Five pull requests closed this week” could mean five shipped changes or five abandoned ones. Count merged and closed separately, and name each: “#132 and #133 merged, #127 closed without merging.” If you need just one kind, filter: is:merged or is:unmerged in the search box above the list.

Colour alone is a weak signal. In bright sun on a phone, purple and grey look almost the same. About 1 in 12 men and 1 in 200 women see some colours differently, most often red and green. And GitHub's appearance settings include colour-blind friendly themes that swap red and green for other colours, so a colleague's screen may not match yours at all.

That's why GitHub pairs every state colour with a shape and a word: a tick, a cross, a dashed line, two lines joining; “Merged”, “Draft”, “Closed”. Read those first.

The same habit applies when you write or speak about states. Name them:

• “#133 is merged.”
• “#136 is still a draft.”
• “#138 was closed as not planned.”

Never “the purple one” or “the grey one”. A colour word forces the reader to see what you see, and some of them can't. A state word works for everyone, on every screen and in every theme, and it still makes sense when read out loud at a meeting.

Issues have their own icons, and they're all circles, which tells them apart from pull requests at a glance. As of 2026:

• Open: a circle with a dot in the middle, green.
• Closed as completed: a circle with a tick, purple. The work is done. Purple means “finished” here, just as on a merged pull request.
• Closed as not planned: a circle with a slash, grey. The team decided against it.

When someone closes an issue, GitHub asks for the reason, and the icon follows it. A team that decided not to show prices in euros closes that idea as not planned instead of pretending it was done. From a terminal: gh issue close 138 --reason "not planned". GitHub also offers “duplicate” as a reason.

For a PM the difference is the difference between shipped and dropped. Both issues are closed, but only one means someone did the work. When you report on issues, never count the two together. And remember that a purple merged pull request and a purple completed issue share a colour but not a shape.

GitHub checks are the automated runs GitHub shows on every commit of a pull request: building the site, running the tests, deploying a preview. A team can make some of them required status checks, so a pull request can't merge while one of them fails.

Each check reports one of four results (as of 2026):

• a circle with a tick, green: passed;
• a circle with a cross, red: failed;
• a dot, yellow: queued or still running;
• grey, often a circle with a slash: skipped or neutral; the check didn't run or gave no verdict.

The small mark next to a pull request's title in the list sums up all its checks: one red cross means at least one check failed. Open the pull request, or run gh pr checks 137, to see which one.

Read the result for what it is: a statement about that branch. A red cross on Dependabot's #137 means its library update broke a test on its own branch. The live site, built from main, is fine.

A grey, skipped check is the sneakiest result on the page. It looks calm, it isn't red, and as of 2026 a skipped job doesn't block the merge, even when that check is required. GitHub treats it as “nothing to complain about”.

But skipped means the check didn't run. Nobody built that preview, nobody ran those tests. It's like a checkpoint with an empty booth and a raised barrier: cars get through, and nobody looked inside.

Checks get skipped for ordinary reasons: a workflow runs only when certain files change, a bot's pull request doesn't get secrets, or a job depends on another one that failed. On Dependabot's #137, preview was skipped, so there's no preview link to click through.

What this means for a PM:

• Don't report a skipped check as “all green”.
• If the skipped check covers what you need to review (the preview, say), ask why it didn't run before you approve.
• In a status update, say it plainly: “test failed, preview was skipped”.

Reviews have icons too. On the pull request page they sit next to each reviewer's name in the sidebar (as of 2026):

• a tick: approved, this can be merged;
• a file with a plus and a minus: changes requested, something must change first;
• a speech bubble: commented, feedback without a verdict;
• a small dot: the review was requested and is still waiting; that person hasn't reviewed yet.

In the pull request list, each row sums the reviews up in words: “Review required” (no approving review yet), “Approved” or “Changes requested”. A Dependabot pull request that nobody has looked at says “Review required”.

Two things to keep in mind. A comment is not an approval: a reviewer who only asked questions hasn't said “yes”. And a waiting dot next to your own name means someone is blocked on you. A quick filter for that: review-requested:@me in the pull request search, or gh pr list --search "review-requested:@me" in a terminal.

Labels are the one place where colour means nothing on GitHub's side. Whoever creates a label picks its colour. New repositories start with a few defaults, such as a red bug, but a team could make bug pink tomorrow, and a blue label is blue only because someone chose blue.

So keep two things apart:

• the state comes from the icon on the left of the row: open, draft, merged, closed;
• the label says what the item is about: bug, checkout, content, idea, dependencies.

A red bug label on an open pull request is simply an open pull request about a bug. It doesn't mean urgent, failed or blocked. A blue dependencies label doesn't mean the checks passed or that the pull request is waiting for review. Some labels are added automatically: Dependabot puts dependencies on its own pull requests.

A small label set is easier to read than a big one. Five labels the whole team understands beat fifty in twelve colours. To filter by one: gh pr list --label bug.

At the bottom of Conversation, the merge box says what still stands between the pull request and a merge. As of 2026 it can show:

• Review required: no approving review yet. Blocked.
• Changes requested: a reviewer asked for changes. Blocked.
• Some checks were not successful: a check failed. Blocked if that check is required.
• Some checks haven't completed yet: checks are running. Wait.
• This branch is out-of-date with the base branch: when the rules require an up-to-date branch, press Update branch.
• This branch has conflicts that must be resolved: someone has to resolve them first.
• All checks have passed and no conflicts, plus an approval: the merge button turns green.

Update branch merges the base branch into the pull request's branch (in a terminal, gh pr update-branch 134). That's a new commit, so the checks start again, now testing the change together with everything that reached main since. The exact wording drifts from year to year; the meaning doesn't.

Keep the two endings of a pull request apart. A merged pull request brought its commits into the base branch. A closed one was shut without a merge, and nothing from it reached the code. Both sit under Closed in the list, so read the icon, not the tab.

At CatChow, a merge of #134 into main sets off a chain:

• With Squash and merge, main gets one commit: “Fix checkout button after cart edits (#134)”.
• The closing keyword Fixes #131 closes issue #131 as completed: a circle with a tick.
• The merged branch is deleted automatically, a repository setting the team switched on.
• The deploy starts. “Merged” becomes “live” only when it finishes, within minutes; then it's worth one look at the live site on a phone.

And the three questions to ask about any merge: merged into what, when, and is it still there? For #134: main, 9:40, and yes, nobody has reverted it.