GitHub Is Hiding Your Repo's Real Health Score

GitHub's built-in Insights tab provides basic visibility into repository activity, but if you're an Engineering Manager or Staff Engineer responsible for repository health, you've likely found it lacking. Traffic stats and contributor graphs don't tell you what you actually need to know: Is this codebase slowing us down? Are we maintaining quality standards? How does this repo compare to our others?

This guide covers the repository-level metrics that actually matter, how to track them across multiple repos, and when to intervene based on repository health signals.

GitHub's Built-in Insights: What's Missing

What GitHub Provides

GitHub's Insights tab offers several views:

• Pulse: Recent activity summary (PRs, issues, commits)
• Contributors: Commit counts per author with graphs
• Traffic: Clone and visitor counts (2-week window only)
• Commits: Commit frequency over time
• Code frequency: Lines added/deleted over time
• Network: Fork and branch visualization

What's Missing for Engineering Leaders

These views are useful for understanding activity, but they don't answer the questions engineering leaders actually need answered:

• No velocity metrics: How long do PRs take to merge? Where are the bottlenecks?
• No quality signals: What's our review coverage? How often do we bypass approvals?
• No comparative analysis: Is this repo healthier or less healthy than our others?
• No actionable thresholds: When should I be concerned? What's "good" vs "needs attention"?
• No process visibility: How effective is our code review? Are PRs sitting idle?
• No trend analysis: Is this repo getting better or worse over time?

GitHub shows you what happened, but not whether that's good, bad, or actionable. For repository health management, you need metrics that connect to outcomes.

Repository Health Metrics That Matter

The most useful repository-level metrics fall into three categories: velocity, quality, and team health. Here's what to track for each.

Velocity Metrics

PR Cycle Time measures the elapsed time from PR open to merge. This is your single most important repository health metric because it directly measures how fast the team can ship changes in this codebase.

• Why it matters: Long cycle times indicate process friction, review bottlenecks, or complex codebases that slow teams down
• What "good" looks like: Most healthy repos maintain cycle times under 48 hours. Legacy or complex repos may run 2-4 days, which is acceptable if consistent. Cycle times over 5 days indicate serious problems.
• Red flags: Cycle time increasing month-over-month, or high variance (some PRs merge in hours, others take weeks)

Time to First Review measures how long PRs wait before receiving their first review comment or approval. This is typically the largest component of cycle time.

• Why it matters: Long wait times frustrate engineers and indicate review capacity issues
• What "good" looks like: Elite teams achieve first review within 4 hours. Most healthy teams aim for same-day (8-12 hours).
• Red flags: Average first review time over 24 hours, or PRs frequently sitting for multiple days before any reviewer engagement

Throughput (PRs Merged/Week) provides a simple measure of repository activity. While not a perfect productivity metric, it's useful for identifying changes in team capacity or repository abandonment.

• Why it matters: Sudden drops in throughput signal team changes, shifting priorities, or process problems
• What "good" looks like: Consistent week-over-week throughput, appropriate to team size (3-5 PRs per engineer per week is typical)

Quality Metrics

Review Coverage measures what percentage of merged PRs received at least one approval before merging. This is a leading indicator of code quality.

• Why it matters: Unreviewed code is significantly more likely to introduce bugs, security issues, or technical debt
• What "good" looks like: 95-100% review coverage for production code repositories. Documentation repos may have lower standards.
• Red flags: Coverage below 90%, or declining coverage over time

For more on review practices, see our Review Coverage Guide.

Merge Without Approval Rate tracks the percentage of PRs merged without receiving an approval. This is the inverse of review coverage but highlights process bypasses.

• Why it matters: Frequent approval bypasses suggest either weak branch protection or a culture of cutting corners
• What "good" looks like: Under 5%, ideally 0% except for emergency hotfixes

Average PR Size measures the typical number of lines changed per PR. Smaller PRs are easier to review, less likely to contain bugs, and faster to merge.

• Why it matters: Large PRs slow down reviews, reduce review effectiveness, and increase cycle time
• What "good" looks like: Research suggests keeping PRs under 400 lines of code for optimal review effectiveness. Many high-performing teams target 200-300 lines.
• Red flags: Average PR size over 500 lines, or frequent PRs exceeding 1,000 lines

See PR Size Optimization Guide for strategies to reduce PR size.

Test Failure Rate tracks what percentage of CI builds fail. This indicates both code quality and CI pipeline health.

• Why it matters: High failure rates suggest flaky tests, brittle code, or inadequate local testing before pushing
• What "good" looks like: Under 10% failure rate. Above 20% indicates serious issues.

For more details, see Test Failure Rate Guide.

Team Health Metrics

Active Contributors counts unique developers who authored PRs or commits in the time period (excluding bots).

• Why it matters: Very few contributors suggests knowledge silos or lack of team engagement. Too many contributors can indicate poor ownership boundaries.
• What "good" looks like: 3-8 active contributors for most service repos. Monorepos or platform repos may have 15-30+.

Reviewer Load Distribution measures how review work is spread across the team. Concentrated review loads create bottlenecks and burn out senior engineers.

• Why it matters: If one person is reviewing 40% of PRs, they're a bottleneck and at risk of burnout
• What "good" looks like: Review load distributed fairly, with no single person handling more than 25% of reviews

See Review Load Balancing Guide for strategies to distribute review work.

Activity vs Quality Metrics

A critical distinction often missed: activity metrics measure what happened, while quality metrics measure how well it happened.

Activity Metrics (Useful but Limited)

These metrics show volume but not effectiveness:

• Commit count: Shows activity but not value
• Lines of code changed: More isn't better
• PR count: Can be gamed by splitting work artificially
• Issue count: Doesn't distinguish valuable work from noise

When to use activity metrics: Spotting sudden drops (team change, priority shift), comparing relative scale between repos (busy vs quiet), and identifying abandoned repositories.

Quality Metrics (More Actionable)

These metrics indicate how healthy the development process is:

• Cycle time: Fast cycle time = efficient process
• Review coverage: High coverage = quality standards enforced
• Test failure rate: Low rate = reliable CI and careful development
• PR size: Small PRs = better decomposition and review quality

When to use quality metrics: Identifying process problems before they cause incidents, justifying process improvements to leadership, and comparing repository health across teams.

The Balance

Healthy repositories show strong quality metrics and appropriate activity levels. Watch for these patterns:

Healthy repo:
  Activity: 20-30 PRs/week
  Cycle time: 24-36 hours
  Review coverage: 98%
  Test failures: 8%
  → High activity with good quality standards

Quality-first repo:
  Activity: 8-12 PRs/week
  Cycle time: 48-72 hours
  Review coverage: 100%
  Test failures: 3%
  → Thorough but slower (may be appropriate for critical systems)

Velocity-first repo:
  Activity: 40-60 PRs/week
  Cycle time: 12-18 hours
  Review coverage: 75%
  Test failures: 18%
  → Fast but sacrificing quality (risky for production code)

Problem repo:
  Activity: 2-5 PRs/week
  Cycle time: 5-7 days
  Review coverage: 60%
  Test failures: 25%
  → Low activity AND poor quality = needs immediate attention

Multi-Repository Rollups

Most engineering organizations manage multiple repositories. Rolling up metrics across repos provides org-level visibility while preserving per-repo drill-down.

Aggregation Strategies

Sum metrics for total activity across the organization:

• Total PRs merged (across all repos)
• Total commits
• Unique active contributors (deduplicated)
• Total lines changed

Average metrics weighted by activity for process health:

• Organization-wide cycle time (weighted by PR volume per repo)
• Average review coverage
• Average PR size

Simple averages are misleading. A repo with 2 PRs and 10-day cycle time shouldn't equally weight against a repo with 200 PRs and 1-day cycle time.

PR-weighted average calculation:

Example:
  Repo A: 100 PRs, 2-day cycle time
  Repo B: 10 PRs, 5-day cycle time
  Repo C: 50 PRs, 3-day cycle time

Simple average: (2 + 5 + 3) / 3 = 3.33 days
PR-weighted:    (100×2 + 10×5 + 50×3) / 160 = 2.5 days

The weighted average better reflects what engineers actually experience.

Repository Comparison Views

Effective multi-repo dashboards allow side-by-side comparison:

Repository Health Scorecard:

| Repository     | Cycle Time | Review Cov | PR Size | Test Fail | Health |
|----------------|------------|------------|---------|-----------|--------|
| payments-api   | 1.8 days   | 98%        | 245 loc | 9%        | A      |
| user-service   | 2.1 days   | 95%        | 312 loc | 12%       | B+     |
| frontend-web   | 1.2 days   | 100%       | 198 loc | 7%        | A+     |
| legacy-monolith| 4.5 days   | 72%        | 892 loc | 28%       | D      |
| mobile-ios     | 2.8 days   | 89%        | 445 loc | 15%       | B-     |

Trend indicators:
  ↑ = Improving over last 30 days
  ↓ = Declining
  → = Stable

This view immediately highlights problem repositories (legacy-monolith) and best-in-class examples (frontend-web) that others can learn from.

For more on multi-repo metrics management, see Monorepo vs Multi-Repo Metrics.

Setting Repository-Level Targets

Once you're measuring repository health, the next question is: what should we aim for?

Establishing Baselines

Before setting targets, establish current state:

1. Collect 2-4 weeks of data to understand typical performance
2. Calculate percentiles (p50, p75, p90) for each metric to understand variance
3. Compare to benchmarks using industry research (DORA, State of DevOps)
4. Identify outlier repos - both best-in-class and problematic

Target-Setting Strategies

Strategy 1: Improvement-Based

Set targets as incremental improvements over current baseline:

• Current cycle time: 3.2 days → Target: 2.5 days (22% improvement)
• Current review coverage: 82% → Target: 90% (pragmatic step toward 95%+)
• Current test failure rate: 18% → Target: 12%

Pros: Achievable, motivating, accounts for your current state

Cons: May anchor you to low baseline (if you're currently terrible)

Strategy 2: Benchmark-Based

Set targets based on industry benchmarks or high-performing teams:

• Target cycle time: 48 hours (aligned with "high performer" tier)
• Target review coverage: 95% (industry standard for production code)
• Target test failure rate: 10% (acceptable baseline)

Pros: Aspires to industry standards, easier to justify to leadership

Cons: May be unrealistic given your current constraints

Strategy 3: Hybrid Approach (Recommended)

Combine incremental improvement with aspirational benchmarks:

Example: Cycle Time Targets

Current state: 4.2 days
Industry high performers: 1-2 days

Phased targets:
  Q1 2025: 3.5 days (17% improvement, achievable)
  Q2 2025: 2.8 days (20% improvement, stretch goal)
  Q3 2025: 2.2 days (21% improvement, approaching benchmark)
  Q4 2025: 1.8 days (18% improvement, high performer tier)

This gives the team quarterly wins while working toward industry benchmark.

Per-Repository vs Org-Wide Targets

Should all repos have the same targets? Not always:

• Production services: Strict quality targets (95%+ review coverage, low test failures)
• Internal tools: More lenient quality, faster cycle time acceptable
• Documentation repos: Speed emphasized over review rigor
• Legacy repos: Improvement trajectory matters more than absolute targets

Set org-wide targets for visibility, but allow per-repo adjustments based on context.

Alerting on Repository Health

Dashboards require someone to actively check them. Alerts flip the model—they come to you when a repository needs attention.

Essential Repository-Level Alerts

Configure alerts for each critical metric:

Alert: Repository Cycle Time Elevated
  Repository: payments-api
  Metric: cycle_time_hours
  Threshold: > 72 hours (3 days)
  Period: Weekly average
  Severity: Warning
  Description: "Payments API cycle time exceeds target. Check for:
    - Blocked PRs awaiting review
    - Complex changes requiring multiple rounds
    - Reviewer availability issues"

Alert: Review Coverage Drop
  Repository: user-service
  Metric: review_coverage_percent
  Threshold: < 90%
  Period: Weekly
  Severity: Critical
  Description: "User service review coverage dropped below 90%.
    Ensure branch protection is enabled and enforced.
    Review recent merged PRs without approval."

Alert: Test Failure Rate High
  Repository: frontend-web
  Metric: test_failure_rate_percent
  Threshold: > 15%
  Period: Daily
  Severity: Warning
  Description: "Frontend test failure rate elevated.
    Check CI logs for flaky tests or recent changes
    that introduced failures."

Comparative Alerts

Alert when a repository deviates significantly from org average:

• Repo cycle time 50%+ slower than org average
• Repo review coverage 15%+ below org average
• Repo test failure rate 2x org average

These highlight repositories that need attention or may benefit from process improvements that worked elsewhere.

Trend Alerts

Alert on negative trends even if absolute values are still acceptable:

• Cycle time increased 30%+ over last 30 days
• Review coverage declined 10%+ over last month
• PR throughput dropped 40%+ (may indicate team changes or priority shifts)

For comprehensive guidance on alerting strategy, see Alert Rules Guide.

Getting Started with Repository Metrics

Implementing repository-level metrics doesn't require a massive upfront investment. Start small and expand based on what you learn.

Phase 1: Baseline (Week 1-2)

1. Connect your repositories to your metrics tool (or start tracking manually)
2. Focus on 3 core metrics: Cycle time, review coverage, and PR throughput
3. Collect data without setting targets to understand current state
4. Identify your best and worst repos for later investigation

Phase 2: Analysis (Week 3-4)

1. Compare repos side-by-side to identify patterns
2. Interview teams with best-performing repos to understand what they're doing right
3. Diagnose problem repos - is it process, team size, technical debt, or external dependencies?
4. Set initial targets based on realistic incremental improvement

Phase 3: Action (Ongoing)

1. Configure alerts for critical metrics to catch regressions early
2. Share metrics with teams - make repository health visible
3. Run experiments on struggling repos (adjust review assignments, refactor hot paths, etc.)
4. Celebrate improvements when repos hit targets
5. Review quarterly and tighten targets as you improve

Common Implementation Mistakes

• Tracking too many metrics at once: Start with 3-5 core metrics, expand later
• Comparing unfairly: Account for repo differences (age, team size, domain complexity)
• Setting unrealistic targets: Aim for 20-30% improvements, not 10x
• Ignoring context: A spike in cycle time during a major refactor may be healthy
• Measuring without acting: Metrics are only useful if they drive improvements

Building the Habit

Repository health metrics are most effective when reviewed regularly:

• Weekly team check-ins: Review repository metrics with team leads
• Monthly engineering reviews: Present repo health scorecard to leadership
• Quarterly retrospectives: Assess what improved, what didn't, and why

For a structured approach to regular reviews, see our Engineering Metrics Dashboard Guide.

The goal isn't perfect metrics—it's better visibility into repository health so you can identify problems early and make data-informed decisions about where to invest engineering effort.