GitHub Issue Hierarchy
The GitHub Issue Hierarchy page shows GitHub issues with their parent/child relationships for repositories where those relationships have been resolved and cached by TeamGlimpse.
Use it to answer questions like:
- What are the parent epics for the issues my team is working on?
- Which sub-issues belong to a given parent?
- Which open issues lack a parent and may need triage?
Getting started
Navigate to Issue Hierarchy → GitHub in the sidebar. The GitHub data source must be configured.
- Pick a repository from the dropdown (populated by the configured token’s visible repositories).
If TeamGlimpse cannot list repositories — for example a token without the
reposcope on a private installation — the dropdown is replaced by a free-text box where you typeowner/repoyourself. - Type into the search box — either issue numbers or search qualifiers. Leaving it empty is fine, and returns everything.
- The page renders matching issues with their resolved parent chain, depth indicators, and direct links to GitHub.
What you can type in the search box
The box accepts two different kinds of input, and decides which one you meant from what you typed. There is no mode switch.
Mode 1 — issue numbers (exact lookup)
Used when every token you typed is an issue number. The page fetches exactly those issues by number and adds their parents and children as context rows.
| You type | Result |
|---|---|
173 | issue 173 |
#173 | issue 173 — the # is optional |
137 173 | issues 137 and 173 |
137, 173 | same — commas work as separators |
137 OR 173 | same — OR (any capitalization) is treated as a separator |
173 173 137 | issues 173 and 137 — duplicates are dropped, your order is kept |
Separators are spaces, tabs, and commas. Numbers must be positive whole numbers.
These are not accepted as numbers, and fall through to Mode 2 as text: 0, -5, # on its own, 17a, 1#7.
Number mode applies no state filter — an issue is returned whatever state it is in.
Mode 2 — search qualifiers
Used for anything else. Your text is passed to GitHub’s issue search verbatim, scoped to the selected repository. The syntax is exactly GitHub’s issue search syntax — the full list of qualifiers lives there; the common ones:
| You type | Meaning |
|---|---|
| (empty) | every issue in the repository, any state |
is:open / is:closed | filter by state |
label:bug | has the bug label |
label:bug label:p1 | has both labels |
assignee:@me | assigned to the token’s own account |
no:assignee | unassigned |
milestone:"Q2 hardening" | in that milestone — quote values containing spaces |
author:some-user | opened by that account |
updated:>2026-01-01 | changed since a date |
payment retry | free-text search of title, body, and comments |
Plain words are a full-text search. GitHub indexes comment bodies, so a word can match an issue that only mentions it in a comment — this is why numbers get their own exact-lookup mode.
Qualifiers that are rejected
These are blocked because they would move the search outside the repository you selected, past the access your administrator granted. Using any of them returns an error instead of results:
repo: · org: · user: · archived: · fork:
The check is case-insensitive and matches anywhere in your text. To search a different repository, pick it from the dropdown.
Things the page always applies for you
You do not need to type these, and they cannot be overridden:
is:issue— pull requests never appear in the hierarchy, even if you typeis:pr.- Sorting by last updated, newest first.
- The selected repository as the search scope.
Issue state
An empty query matches issues in every state — open and closed. Add is:open or is:closed to narrow it. This matches the GitLab, Azure DevOps, and Jira hierarchy pages.
| Data source | Default state filter | How to narrow |
|---|---|---|
| GitHub | All states | is:open / is:closed |
| GitLab | All states | state=opened / state=closed selector |
| Azure DevOps | All states | State selector |
| Jira | All states | JQL, e.g. statusCategory != Done |
Show parents / Hide parents
The Show parents / Hide parents selector next to the Load button controls ancestor context:
- Show parents (default) — issues that did not match your query are still shown when they are the parent of something that did, so you can see the epic a matched sub-issue belongs to. These rows are dimmed.
- Hide parents — unmatched ancestors are dropped and matched issues become top-level rows. Children of matched issues are still shown.
Changing it re-renders immediately; you do not need to click Load again. The setting is part of the page URL, so it survives sharing and reload.
How hierarchy is resolved
Every search resolves the hierarchy live against GitHub. TeamGlimpse first checks whether the repository’s host supports GitHub’s sub-issues API, then takes one of three paths:
- Sub-issues supported (the normal case). TeamGlimpse asks GitHub for the sub-issues of every
issue in the result set, and builds the parent/child links from the answer.
- Children that your search did not match are fetched too, so a matched parent shows its children. At most 50 such out-of-set children are fetched per search, to protect your organization’s shared GitHub rate limit.
- Parents that your search did not match are fetched upward as well, so a matched sub-issue shows the epic it belongs to. The walk goes up at most 5 levels per search (in practice a chain is only one or two deep), and pull requests are never shown as hierarchy rows.
- Sub-issues not available on this host or repository. TeamGlimpse falls back to milestones as parents: each milestone in the result set becomes a top-level row and every issue is nested under its own milestone. Issues with no milestone stay top-level. The page shows the “sub-issues unavailable” notice in this case.
- GitHub was momentarily unreachable when checking for sub-issues support. TeamGlimpse falls
back to its local cache of previously resolved parent chains, so the page still renders. Issues
with no cached chain appear without a parent. Cache entries are retained for 24 hours per
(organization, repo, issue).
Everything TeamGlimpse fetches along the way warms that cache, so repeat searches are cheaper.
Rate limits
The page consults two separate GitHub REST quotas:
- Repository list counts against the Core quota (5,000 requests/hour for personal tokens). Repos are cached client-side for ten minutes, so the dropdown rarely hits the API after the first load.
- Issue search counts against the Search quota (30 requests/minute for personal tokens). The page submits one search per explicit user action — there is no auto-refresh.
If you exceed either quota, the BE returns a 429 Too Many Requests and the page shows the remaining wait time.
Limitations
- The fan-out per search is capped. At most 50 unmatched children are fetched, and the parent walk stops after 5 levels. A very wide result set can therefore leave a few relationships unshown; narrowing the search brings them back.
- The search results are capped at 100 issues per query — the maximum GitHub’s search API returns in one page. Results are ordered by last updated, newest first, so the cap drops the least recently updated matches. When it does, the page shows an amber “more issues matched than can be shown” notice; narrow the search with additional qualifiers to reach the rest.
- Because an empty query now matches every state, wide-open searches on long-lived repositories hit that cap far more often than they used to. Add a qualifier (
is:open,label:…,milestone:…) when you need completeness. - Cycles in the sub-issues graph are detected and broken — a cycle never causes the page to spin.
Related pages
- Worklog — recent activity on the issues you find via the hierarchy.
- Value Stream — cycle-time analysis for the issues that surface here.