GitHub added a Trends tab to the organization-level Code Quality dashboard on 19 August. It plots open findings over 7, 14 or 30 days, grouped by health score or severity, with net change and a repository ranking by how much each one moved.
It is available on Enterprise Cloud and Team plan organizations with Code Quality enabled, not on Enterprise Server. The dashboard itself is straightforward. Reading it correctly is not, because the obvious interpretation of a rising line is usually wrong.
A rising trend is not automatically bad news
The instinct is to read more open findings as things getting worse. That is true only if the underlying code changed for the worse, and there are at least two other explanations that produce the identical graph.
Enabling a new check adds findings for code that has not changed at all — you just started measuring something you were not measuring before. And someone finally running a scan on a repository that had been neglected surfaces a backlog that was always there, not a new problem being created.
Before treating a rising line as a regression, check what changed on the measurement side, not just the code side: did the ruleset change, did a repository get onboarded, did severity thresholds move.
The repository ranking is the actually useful view
The trend line answers "is this getting better or worse" at the organization level, which is a vague question with a vague answer. The repository ranking answers something specific: which repositories are moving, and in which direction.
That is the view worth checking regularly, because it turns an abstract quality metric into a short, actionable list — the repositories improving fastest are worth understanding so you can repeat what worked, and the ones declining are worth a conversation before the backlog compounds.
Setting a review cadence
The three time windows serve different purposes, and using all three for the same question wastes the feature.
- 7 days — noise-sensitive, good for catching a sudden spike right after a specific change, not for judging a team
- 14 days — the practical default for a recurring review; long enough to smooth day-to-day variation, short enough that a conversation about it is still timely
- 30 days — for the organization-level report, where the question is direction over a quarter rather than what happened this sprint
Filter before you conclude anything
The graph and rankings respect whatever repository filters are set at the top of the page, and using them changes what the numbers are actually saying.
An unfiltered organization-wide view mixes actively developed repositories with dormant ones, and a dormant repository cannot generate new findings, so it silently drags the average toward "stable" regardless of what active work looks like. Filter to repositories with real commit activity in the window before drawing any conclusion about whether quality is trending up or down.
What the dashboard cannot tell you
It counts findings, not consequences. A count treats a minor style violation and a serious security finding as comparable line items unless you have grouped by severity, so grouping by severity rather than raw count is the setting that actually matters for a security-minded read.
It also cannot tell you whether the code shipped or was reverted, whether a finding was fixed or suppressed, or whether the team that owns a declining repository knows about it yet. Those require pairing this dashboard with the same review-effort and PR data GitHub has been adding elsewhere this month — a declining trend paired with lighter code review effort tells a different story than a declining trend on its own.
A fifteen-minute monthly routine
Enough to catch drift without the dashboard becoming a second job.
- Open the 30-day view, filtered to active repositories, grouped by severity
- Check the repository ranking for anything moving the wrong direction for more than one review cycle in a row
- For anything that qualifies, check what changed — a new ruleset, an onboarded repository, or actual code — before concluding it is a real regression
- Send the ranked list to repository owners rather than a summary judgement; let them supply the context the dashboard cannot