How to search GitHub issues across every repo in your org at once
Type org:your-org is:issue is:open into GitHub's search bar and you get every open issue across every repo you have access to, in one list, sorted by whatever you pick. That's the whole trick for a one-time look. What GitHub's search doesn't give you is a way to keep that list live, grouped, or deduplicated once you have more than a handful of repos filing issues.
So the honest answer is: native search already solves "one view" for the moment you run it. It stops solving anything the moment you want that view to persist, update itself, or tell you that the three-word bug report in repo-mobile and the paragraph-long one in repo-api are the same complaint.
The org: qualifier does what it says
GitHub's search documentation says plainly that to search issues and pull requests across every repository owned by a user or organization, you use the org: qualifier instead of repo:. So org:your-org is:issue is:open label:bug returns matching issues from all 40-something repos in one pass. No Enterprise plan required, no scripting required. It's a plan-agnostic feature, not a gated one, which is worth knowing because a lot of the frustration people bring to this problem assumes it isn't there.
The same qualifier works from the command line. The GitHub CLI's search command takes --owner for exactly this case:
gh search issues --owner your-org --state open --label bug --limit 100That's useful for anything you want to pipe into a script, a Slack digest, or a scheduled report, since it returns structured output instead of a rendered page.
Where it stops being one view
The qualifier answers "show me," not "keep showing me" or "these are the same thing." Three gaps show up quickly once an org passes a few dozen repos:
- No standing board. GitHub Projects can span multiple repos, but the auto-add automation that keeps a project table current cannot. GitHub's own docs on automating projects with Actions say it plainly: "a workflow is specific to a repository. Add the workflow to each repository that you want your project to track." A search result is a snapshot; a project table that mirrors 40 repos needs 40 workflows kept in sync, or issues added by hand.
- No dedupe. The search returns rows, not clusters. If the same request lands as
"can we get SSO"in one repo and"enterprise login when"in another,org:search shows you both, separately, with no signal that they're the same ask. A community thread on listing issues org-wide works through the same three workarounds (search, GraphQL, Projects) and lands on the same conclusion: nothing native groups related issues across repos, so you read them and connect the dots yourself. - Automation needs the GraphQL API. For anything beyond an ad hoc look, teams end up writing GraphQL queries that walk each repo's issue list, which works but comes with per-repo pagination and rate limits to manage. That pattern shows up in the same community thread, and again in a request to auto-add issues from multiple repos into one Projects table, open with 68 thumbs-up reactions since February 2023 without a native fix.
None of this is a defect in GitHub search. It's a scope mismatch: search is built to answer a question you ask once, not to run as infrastructure.
What the search missed at Yumiko Tanaka's shop
Yumiko Tanaka is the staff platform engineer at a warehouse-robotics vendor called Bellhaven Systems. By the time she took the role, the codebase had split into 44 repos, one per robot subsystem, plus the dashboard, the API gateway, and a handful of internal tools. Bug reports and feature requests came in as GitHub issues on whichever repo the customer's integration touched, which meant nobody had a single place to see what customers were asking for across the fleet.
Yumiko's first fix was the obvious one: a saved org:bellhaven is:issue is:open label:customer-facing search, bookmarked and checked every Monday.
She logged what happened next as a comment on the internal issue she'd opened to track the cleanup:
"The saved search works, it's just slow to read. I counted eleven open issues about the same thing last week: three different repos, three different wordings, all describing 'the fleet-status webhook drops packets under load.' I only caught that because I read all eleven titles carefully. If I'd skimmed, I'd have filed it as three separate small problems instead of one big one."
The search had done its job. It surfaced every issue. What it couldn't do was tell her that eleven issues were one, or keep a running count as new ones came in through the week. She started a spreadsheet to track recurring themes by hand, which worked until the spreadsheet itself needed its own weekly upkeep.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhere this stops scaling, and what picks it up
The pattern holds for any org past a certain repo count. Search finds everything, but a person still has to read every result to notice duplicates, and that reading gets redone every week because nothing remembers last week's grouping. Teams that automate around this usually build a script against the GraphQL API that pulls issues org-wide on a schedule and writes them somewhere durable. That solves "persistent" but not "deduplicated," since the script still has to guess which issues are the same ask in different words.
That's the point where we'd bring up Modem. Modem connects to your GitHub repos the same way the org: search does: it isn't scoped to one repo. But it reads every connected repo continuously rather than on a search you have to remember to run, and it clusters issues that are the same request into one counted topic, whatever the wording. Yumiko's eleven-titles problem is exactly the case: the same underlying report, phrased three different ways, arrives as one topic with all eleven issues attached instead of eleven rows a human has to reconcile. When a fix for that topic ships and the pull request merges, Modem also matches the merge back to the topic, which is the piece a GraphQL script wouldn't get even with the dedupe problem solved. Below 40 repos, or below a few dozen issues a week, the saved org: search plus a Monday read-through is genuinely enough. The automation is worth building once that read-through stops fitting in the time available for it.
If your issues are mostly internal engineering work rather than customer-reported requests, the sweep-and-label discipline in how to triage GitHub issues at scale is the better starting point. Org-wide search finds the issues; a triage rotation is what keeps them from piling up once found. And if the requests pulled out of GitHub need to end up somewhere your whole team already tracks feedback, our roundup of tools that turn customer feedback into GitHub issues covers the other direction of that same pipeline.
Start with the search, add process only when it earns it
Save an org:your-org is:issue is:open search. Add a label filter if you already tag customer-facing issues, and put a fifteen-minute read-through on your calendar once a week. Under a few dozen open issues a week, that's a complete answer to "one view across every repo." Watch two things after that: how long the read-through actually takes, and whether you're retyping a summary of an issue you already read in a different repo last week. Either one creeping up is the real signal, not a repo count or issue count you could have planned around in advance.
