5.1 Insights, Stars, Dashboards, and Dependency Insights

Why GH-900 tests repository visibility

Domain 2 of GitHub Foundations (GH-900) is 10–15% of the exam. After you can create a repository and manage files, the January 2026 outline asks you to describe repository insights, stars, feature previews, repository metrics dashboards, and dependency insights for improved visibility. GH-900 is not grading pixel layouts. It is asking whether you can tell a maintainer which graph answers which question, who is allowed to see traffic, when a private repository on GitHub Free loses charts, and how starring differs from watching and forking.

The Insights tab sits in the repository navigation bar (the graph icon). GitHub Docs group these views as repository graphs: traffic, projects that depend on the repository, contributors and commits, and the fork network. If you maintain a repository, this data tells you who is using the project and why they showed up. That is a different surface from GitHub Projects insights in Domain 5, which charts cards on a project board. If a scenario mentions clones, referring sites, Pulse, or the contributors graph, the answer is the repository Insights tab—not a Projects dashboard and not the Security tab.

The seven named insight graphs

GitHub's plans documentation lists seven repository insights graphs: Pulse, Contributors, Traffic, Commits, Code frequency, Network, and Forks. Open the repository, click Insights, then pick the graph in the left sidebar. Learn what each graph is for, because GH-900 scenarios name a business question and expect you to pick the matching view.

Plan limits are the classic discriminator. On public repositories, GitHub Free includes Pulse, Contributors, Traffic, Commits, Code frequency, and Network (Forks listing is available as well). On private repositories, those insight graphs require GitHub Pro, GitHub Team, or GitHub Enterprise Cloud. A personal Free account or GitHub Free for organizations still gets unlimited private repositories, but with a limited private feature set—do not assume every Insights chart is present. GitHub Docs add a second hard cap: certain contributor, commit, and code frequency insights are only available for repositories that have fewer than 10,000 commits. A long-lived monorepo can lose those three graphs even on a paid plan.

Pulse, contributors, commits, and code frequency

Pulse is the overview. It lists open and merged pull requests, open and closed issues, and a graph of commit activity for the top 15 users who committed to the default branch in the selected period. Commit co-authors appear in that summary only when their commits were merged into the default branch and they are among those top 15. Use the Period dropdown when a question is about the last month instead of the default week. Pulse is a snapshot of recent collaboration, not a substitute for git log.

Contributors ranks people who actually landed commits. Only the top 100 appear. Merge commits and empty commits do not count. Commits that never reached the default branch do not count—work sitting on gh-pages is invisible unless gh-pages is the default branch. If a developer is missing from the graph, GitHub's own troubleshooting list is: they are not in the top 100, their commits were not merged to the default branch, or the author email is not connected to their GitHub account. After a force-push or history rewrite, contributor statistics can take about 24 hours to refresh. GH-900 will happily offer “they forgot to star the repo” as a distractor; starring has nothing to do with the contributors graph.

Commits visualizes every non-merge commit from the past year. The upper chart is commits by week; the lower chart is the average number of commits by day of week for the week you select. Code frequency plots weekly additions and deletions, which is how you spot a rewrite week versus a quiet week. Both of those views, plus contributors, sit behind the 10,000-commit ceiling. For a detailed history of pushes, merges, force pushes, and branch changes, GitHub points you to the activity view, which associates those events with commits and authenticated users. Activity view is not Pulse and it is not the Commits graph.

Traffic, network, and forks

Traffic is the only graph in this set that GitHub explicitly gates on push access. You see full clones (fetches do not count), visitors from the past 14 days, referring sites, and popular content. Referring sites exclude search engines and GitHub itself. Referring sites and popular content are ordered by views and unique visitors. Clone and visitor numbers update hourly; referring sites and popular content update daily. All traffic timestamps use UTC+0, regardless of where you sit. Hover a day to read that day's exact counts. A public README reader without push permission cannot open Traffic—that is an exam trap.

The network graph is a timeline of the most recent commits across the repository and its forks. It shows up to 100 of the most recently pushed-to branches. The first row is the date; the first column is the branch owner. Drag to see older branches. Use it when the question is “who branched from whom?” rather than “how many unique visitors?”

The Forks page inventories each fork's star count, number of direct forks, open issues, open pull requests, last push to any branch, and created date. You can filter active, inactive, starred, or archived forks, and restrict the list to forks updated within a window of up to five years. Sort by most starred, most recently updated, most open issues, or most open pull requests. Save those filters as defaults if you review forks often. Forks here are discovery of copies; creating a fork is a collaboration model (Domain 7), not an Insights metric.

Stars, watching, and forking are three different intents

GH-900 lumps stars with Insights because both are visibility signals, but starring is not a graph. Starring a repository (or a topic) bookmarks it on your stars page so you can find it later, shows appreciation to the maintainer, and feeds GitHub rankings—Explore highlights popular repositories by star count. After you star a project, GitHub can surface related work on your personal dashboard. Starring does not subscribe you to issue and pull request notifications. You can organize stars into public lists (public preview; subject to change). If you add a private repository to a list, people without read access do not see that private entry.

Watching is the notification subscription. When you watch a repository you are notified of conversations there. You can instead choose a Custom watch: issues, pull requests, releases, security alerts, discussions, or a mix. Unwatching still leaves @mentions and threads you participate in. Auditing watched repositories is how you cut notification noise; it is not how you bookmark a cool library. Historically GitHub's API called a star a WatchEvent, which is why older material confuses the two—on the exam, use the product meanings: star = save/appreciate, watch = notify.

Forking copies the repository under your account (or an organization) so you can push branches and open pull requests without write access to the original. GitHub's repository best-practices page is blunt: regular collaborators should work in one repository and open pull requests between branches; forking is for people unaffiliated with the project, such as open-source contributors. Forking is a collaboration model, not a metric, even though Insights shows the fork network.

Feature preview is a personal-account toggle

Feature preview is how GitHub lets you try public preview products from your personal account. Click your profile picture → Feature preview, read the short description, then Enable or Disable. Previews are documented but carry no SLA and no technical support obligation. GitHub's release cycle, which GH-900 may paraphrase, has three phases:

• Private preview (including anything labeled Technology Preview): heavy development, may be undocumented, no SLA, no support obligation.
• Public preview: broader distribution, documented, still no SLA or support obligation.
• General availability (GA): production-ready; SLA and support obligations apply.

Feature preview does not replace repository Insights, does not enable paid graphs on a Free private repo, and is not an organization-wide policy switch. If a scenario says a user wants to try a documented-but-unsupported GitHub feature on their own account, Feature preview is the control.

Dependency insights at Foundations level

Almost every project depends on other people's packages. The dependency graph is the visibility map of that supply chain. GitHub builds it by parsing manifest and lock files in the repository and by accepting submissions through the dependency submission API. For each repository it shows:

• Dependencies — ecosystems and packages the repo depends on, with version, license, originating manifest, and whether the package has known vulnerabilities. Ecosystems that support transitive dependencies can show the path that pulled a package in. Vulnerable packages sort to the top.
• Dependents — other public repositories and packages that depend on this one. GitHub does not report dependents for private repositories.

Some public packages also get a Used by count in the Code tab sidebar. That badge appears when the dependency graph is enabled, the repo publishes a package on a supported ecosystem with a link to a public source repo, and more than 100 repositories depend on the package. Organization owners can also open an organization dependency insights dashboard that summarizes dependencies across the org's repositories.

Dependabot alerts sit on top of that graph: GitHub notifies you when a vulnerability in the GitHub Advisory Database matches a dependency, or when a push changes the graph onto a vulnerable version. Alerts appear on the repository Security view and on the dependency graph. Each alert links the affected file, describes severity, and (when GitHub knows it) names a fixed version. Dependabot alerts are free for public repositories; they are the visibility layer GH-900 wants here. Enabling secret scanning, push protection, code scanning, GitHub Advanced Security products, and org-wide security overview is Domain 6—do not drag those configuration details into a D2.4 answer unless the question is simply “how do I see vulnerable packages?” Pull requests that change dependencies against the default branch can also show a dependency review, which is still a visibility feature: it tells reviewers whether the incoming versions are vulnerable.

Exam traps for D2.4

• Private + Free ≠ full Insights. Pulse/Contributors/Traffic/Commits/Code frequency/Network/Forks on private repos need Pro, Team, or Enterprise Cloud.
• 10,000 commits can hide contributor, commit, and code-frequency insights even when the plan is paid.
• Traffic is not public. Push access; 14 days; clones not fetches; UTC+0.
• Contributors ≠ everyone who opened a PR. Default branch, top 100, no merge/empty commits, email must map to a GitHub user.
• Star ≠ watch ≠ fork. Bookmark versus notify versus copy.
• Projects insights ≠ repository Insights. Domain 5 versus Domain 2.
• Dependency graph is visibility; GHAS policy is Domain 6. Know that Dependabot alerts exist and where they surface.