Guides / How to see GitHub Actions across every repository

How to see GitHub Actions status across every repository

Published 2026-09-27 · by the ShipGlance team at Last Ridge

GitHub shows you everything about one repository and very little about all of them at once. There is no organization-wide page that answers "what is running, what is failing, and what is deployed where" across the repositories a team actually ships from. Eight routes get you part of the way. This page compares all of them, from GitHub's own screens to a script you write yourself, and names what each one stops short of.

Every option below is dated: as of 27 September 2026. GitHub ships fast, so the row that ages worst is the API one.

Is there a way to see all workflow runs at once?

Not in the GitHub UI. Every first-party screen is scoped to one repository, and the aggregate screens answer a different question. Here is the full set, with what each is actually for.

Option	Type	What it shows	Where it stops short
The Actions tab	Native	Workflow runs for one repository, newest first	Per repository. A list of runs is not a state: you read an entry per run and infer what is broken now.
The Deployments page	Native	Deployment history for one repository, filterable by environment, with logs, deploy URLs, and the triggering commit	Per repository. There is no organization-wide deployment list. It also shows only what has shipped, never how far the branch has moved past it.
Organization Insights	Native	Usage and performance metrics per organization, repository, workflow, and runner type: minutes, run times, queue times, failure rates	Answers "how much and how reliably", never "what is running right now and what is deployed where". Aggregated over a chosen period, so nothing is live.
Workflow status badges	Native	A live status image for one workflow, embedded wherever you like	Built for a README: one branch of one repository, no rollup, no history, and no notion of an environment.
Actions tab, many browser tabs	Manual	Everything, if you keep fifteen tabs open	The number of tabs is the maintenance cost. Nobody keeps them open, so "is anything broken?" becomes "I will check when someone complains".
Self-hosted open source dashboards	OSS	Multi-repository workflow status, alerting, and wallboard views. GitactionBoard (Apache-2.0, Java, Docker) covers runs, secret and code scan alerts, Teams notifications, and CCTray XML; github-action-dashboard (MIT, ~230 stars) covers run status per branch and pushed its updates over websockets	You run and upgrade it, and you register a GitHub App by hand, including a webhook endpoint and a private key. Each tool encodes one team's opinions. github-action-dashboard is explicitly no longer supported by its author and supports a single organization or user.
Breadth-first infra panels	OSS	CI status as one tile among many, next to uptime checks, DNS, queues, and error logs (for example projects-monitor)	Workflow runs are a side panel, not the model. GitHub is one integration of a dozen, so there is no per-environment deploy state and no drift.
GitHub API plus your own script	DIY	Anything you build, from the REST API: list runs per repository, filter, render, post to Slack	You own all of it: pagination, rate limits, an update path, the honest empty states, and drift. Changed 2026-09-25: run queries now report "2,500+" instead of an exact count past that many matches, and paginate to 1,000 items, so a cross-repo count now needs a date filter or a per-repository sum.
Hosted deployment board (ShipGlance)	Hosted	One live board across every repository in the organization: running runs, failures, the commit deployed to each environment, drift against the branch head, and history	It observes CI/CD and does not run it, so it is not a log viewer, a tracer, or a metrics system: for raw logs use the Actions tab. GitHub.com only today. Free tier with real limits.

What are the four questions none of the simple options answer?

Whatever you use or build, the gap is the same. These are the questions a team asks in the first five minutes of a problem, for every repository at once:

1. What is failing right now? Currently red, on the branch that matters, with a link to the run and the pull request that broke it.
2. What is deployed where? Per environment, the exact commit that is live and which run put it there.
3. What has drifted? Whether the branch head has moved past what is deployed, and by how much. See what deployment drift is and how to detect it.
4. What changed since the last good deploy? The commit range between the last successful deploy and now.

The gap is not a missing screen. It is that three of the four need state assembled per environment, and GitHub's UI shows events per repository. The deployment dashboard guide covers what such a view should get right.

How do you build cross-repository visibility yourself?

The first version is an afternoon. It also tells you what the products spend their time on:

1. List repositories with workflows. One authenticated pass over the organization, then keep only repositories that have workflow files.
2. Fetch status per repository, not per run. GET /repos/{owner}/{repo}/actions/runs with a branch filter, taking the newest run per workflow. Cache it: a naive loop over dozens of repositories every few seconds hits the rate limit, which is why the older self-hosted tools settled on a 15-minute poll.
3. Map runs to environments. Jobs that declare a GitHub environment are deploy stages; everything else is build or test. No extra YAML, and no second copy of your pipeline.
4. Compare deployed commit to branch head to get drift, and give the empty cases names: not run when a lane is quiet, unknown when drift has not been evaluated. See the three honest states.
5. Alert on transitions, not on every event: a deploy failed, a deploy recovered, drift appeared.

Steps 1 to 3 are the afternoon. Steps 4 and 5, done honestly across dozens of repositories, are the product.

Which option should you choose?

• One repository, or a glance now and then. The Actions tab and the Deployments page are fine. Add a workflow status badge to the README.
• Run it yourself, and you like owning infrastructure. GitactionBoard, or write the script above. Budget for the webhook endpoint, the polling, and the pages it does not have.
• Many repositories, deploy state matters, nobody wants to run anything. That is the case a deployment board exists for, and what ShipGlance is.