11.4 Project Insights
Key Takeaways
- Project insights build charts from the items currently in the project; anyone who can view the project can see those charts.
- You can filter the default chart and create custom charts, choosing filters, chart type, and which fields to display.
- Current charts show today's breakdown (for example items per assignee or per iteration); historical charts set the X-axis to Time, and the default Burn up chart plots Open, Completed, and Not planned work.
- Insights does not track archived or deleted items, so auto-archive will shrink what charts can see.
- Project status updates (for example On track or At risk) with Markdown, start date, and target date live on the project side panel and header; they are not repository Insights graphs and not insight charts.
Why GH-900 tests project insights
Domain 5 closes with describe how project insights can be used to track progress and productivity. The skill is literacy, not dashboard design: where the charts live, what they count, who can see them, and how they differ from the repository Insights tab and from status updates. GitHub's About insights for Projects page is the product source. Microsoft's GH-900 outline uses the same word insights; the exam still expects you to refuse the look-alike tab under a repository.
You open insights from the graph icon in the project header. Charts use items added to your project as source data. You filter the default chart and you create your own. When you create a chart you set filters, chart type, and which information is displayed. GitHub states that the chart is available to anyone that can view the project—there is no separate “insights admin” role. If a person can open the board, they can open the charts. If they cannot see the project, they cannot see the charts.
Insights does not track items you have archived or deleted. That sentence is the productivity trap. Auto-archive (section 11.2) cleans the board and removes those items from insight charts. Teams that archive every closed issue after two weeks will see a tidy board and a Burn up chart that no longer includes last month's completed work. Restore from the archive if you need the item in charts again; deleted items are gone from the 50,000-item budget and from insights.
Current charts versus historical charts
GitHub generates two families of chart.
Current charts visualize the project as it is now. Official examples: how many items are assigned to each person, or how many issues sit in each upcoming iteration. Apply the same filter language you use on views (label:bug, assignee:@me, a single-select option) so a chart can answer “upcoming work for the Android label only.” Current charts are for load, mix, and “are we overcommitted this sprint?” They are not a time series.
Historical charts visualize items over time. You set the chart's X-axis to Time. Historical charts track state changes. GitHub plots:
- Open — open issues and open pull requests
- Completed — issues closed as completed, and merged pull requests
- Closed pull requests — pull requests that closed without merge
- Not planned — issues closed as not planned
You can view count or aggregation over time (for example summing a number field such as story points if you configured one). Filters still apply, so a historical chart can be “completed bugs only.”
The default Burn up chart is the historical chart GH-900 will name. It shows progress over a period (GitHub's screenshot uses two weeks) split into Open, Completed, and Not planned so you can spot trends and bottlenecks. Burn up is not the repository Pulse graph and not a GitHub Actions badge. It lives under the project's insights icon. Creating a new chart is: New chart, optional rename, type filters, Save changes, then configure type and axes.
| Chart family | X-axis | Typical question | Default example |
|---|---|---|---|
| Current | A field (assignee, iteration, Status, label) | Who is overloaded this iteration? | Stacked column of items per iteration, split by label |
| Historical | Time | Are we completing work faster than we add it? | Burn up of Open / Completed / Not planned |
Charts are not a substitute for a table of issues. They also do not grant extra permissions: private project, private charts. Organization members without access to the project do not see productivity numbers from it.
Status updates are not insight charts
GitHub's About Projects page lists sharing status updates next to insights, and GH-900 candidates mash them together. They are different tools.
A status update is a high-level note on the project itself. You set a status such as On track or At risk so people can see health without reading every card. You can set a start date and target date. The message supports Markdown. Updates appear in the project's side panel below the description and README (newest on top, full history beneath). After you post one, the current status also shows in the project header and in lists when you browse projects.
Rules that show up as distractors:
- You need write access to add an update. Read access is enough to see status (and to see insights charts).
- You cannot add status updates to a project that is set as a template.
- The form defaults to the previous update's status and dates so you can tweak rather than start from a blank health report.
- Status updates do not change item Status fields, do not close issues, and do not plot a Burn up series. They are communication, not a chart type.
If leadership asks “are we on track for 1 October?” you post a status update with target date and a Markdown summary. If they ask “how many issues did we complete in June versus July?” you open a historical insight chart. Both are Domain 5; they are not interchangeable answers.
Not the repository Insights tab
Every GitHub repository has an Insights tab (graphs). GitHub's About repository graphs page describes Pulse, Contributors, Traffic, Commits, Code frequency, Network, dependency information, and forks. Some of those graphs are limited on private repositories with GitHub Free; contributor and commit graphs also skip repositories with 10,000 or more commits. None of that is project insights.
Domain 2 already taught repository Insights as visibility into code activity. Domain 5's insights are visibility into project items. A question that says “see who committed the most this month” is repository Insights (or the Contributors graph). A question that says “see how many project issues each assignee still owns in iteration 12” is project insights. A question that says “show the fork network” is the repository Network graph. Mixing those tabs is the highest-probability D5.4 miss.
Project insights also are not:
- GitHub Actions usage charts or workflow run badges
- Milestones percent-complete bars (those remain on the milestone page; you can chart items that have a milestone filter)
- Stars or traffic for a README marketing story
- Dependabot or dependency insights from the repository Insights security views
You can filter an insight chart to items in a milestone or iteration, which is how productivity and release tracking meet. The chart still counts project items, not git commits.
Using insights to track progress and productivity
GH-900 wording is “track progress and productivity.” Translate that into chart jobs:
Progress. Historical Burn up: is Completed rising while Open falls? A current chart of Status shows whether work is stuck In progress. A current chart of iteration shows whether the next sprint is already overloaded. Status updates add the human sentence: “On track, blocked on legal review until Friday.”
Productivity. Current chart of items (or summed number-field points) per assignee is the load picture. Filter out label:wontfix so you do not “productivity-shame” people for closed-as-unplanned work. Historical charts of Completed per week show throughput. Because archived items drop out, a team that auto-archives completed work after 14 days will under-count historical Completed unless they keep those items active or accept that insights are a current-board tool for them.
Organization templates can copy insights (section 11.2), so a new team starts with the same Burn up and assignee charts. Auto-add workflows are not copied, so a templated dashboard stays empty until items exist. That is expected, not a broken chart.
Exam scenarios and traps
- “Show how many project issues each person still owns” → current insight chart grouped by assignee, visible to anyone who can view the project.
- “Show completed versus remaining work over the last two weeks” → default Burn up / historical chart with X-axis Time.
- “Why did last quarter vanish from the chart?” → items were archived or deleted; insights do not track them.
- “Pulse, traffic, and contributors” → repository Insights tab, Domain 2, wrong answer here.
- “Tell the org we are At risk in one sentence with a target date” → status update with Markdown, not a chart and not a Discussion post (unless you also write one).
- Charts are not admin-only. View access is enough to read them; write access is for editing the project and posting status updates.
- Template projects cannot receive status updates; they can ship copied insight charts.
- Filtering charts uses the same filter language as views. You do not export to a spreadsheet to slice by label (you can, but GH-900 wants in-product filters).
- Closed-as-not-planned is a first-class historical series. Do not call those items Completed.
Domain 5 in one line: Projects is a user- or org-level table/board/roadmap over issues, pull requests, and drafts; you configure fields, labels, milestones, and built-in workflows; you communicate with saved replies and assignees; you prove progress with project insights and status updates—not with classic boards and not with the repository Insights tab.
How do GitHub Project insights differ from a repository Insights tab?
Which statement about project insight charts is accurate?
A program manager needs a one-look health signal that the project is At risk, a target date, and a short Markdown note stakeholders will see in the project header. Which feature should they use?