How We Calculate Our Metrics: Full Methodology

Other tools hide behind proprietary "Impact Scores" and opaque calculations. CodePulse does the opposite: every metric maps to specific GitHub timestamps and events. This page explains how each metric is computed and what data drives the numbers on your dashboard. If you can query the GitHub API, you can verify every number yourself.

Cycle Time Phases

CodePulse breaks PR cycle time into four non-overlapping phases, each using specific GitHub timestamps. The phases always sum to the total cycle time. A 3-day cycle time on its own tells you nothing. The breakdown shows whether the problem is slow coding, slow review pickup, slow review completion, or slow merging.

Phase 1: Coding Time

Start: first_commit_at (falls back to created_at if no linked commits exist)
End: first_review_requested_at (or PR creation if no review request event exists)

This captures active development work, including pre-PR commits. Most developers start writing code before opening a PR, so using first_commit_at instead of PR creation date gives a more accurate picture of actual coding time.

Phase 2: Waiting for Review

Start: End of Coding phase
End: first_review_at (first review submission, regardless of outcome)

This is idle time: the code is ready, and the author is waiting for someone to pick it up. In teams with review bottlenecks, this is usually the longest phase, and the one most responsive to process changes like review SLAs. See our guide on cutting PR cycle time.

Phase 3: In Review

Start: End of Waiting phase
End: first_approval_at (first approval event)

Active review time, from when the first reviewer starts to when the PR gets approved. Long review times can indicate complex changes that need discussion, or reviewers who start but do not finish promptly.

Phase 4: Merge Time

Start: End of Review phase
End: merged_at

Time between approval and merge. Long merge times often indicate CI queues, merge conflicts, or organizational approval gates. For self-merged PRs (no external review), CodePulse uses the time from last commit to merge.

Cycle Time Breakdown (non-overlapping phases)

  first_commit_at    review_requested    first_review    first_approval    merged_at
       |                   |                 |                |               |
       |--- Coding ------->|--- Waiting ---->|--- Review ---->|--- Merge ---->|
       |                   |                 |                |               |
       |<----------------------- Total Cycle Time --------------------------->|

When an organization has working days configured, all phase durations are calculated in working hours only, excluding weekends and configured holidays. This prevents a PR opened on Friday and merged on Monday from showing 72 hours of cycle time when the actual working time was 8 hours.

DORA Metrics

CodePulse calculates all four DORA metrics. When deployment data is available (via the GitHub Deployments API or configured deployment events), it uses real deployment timestamps. Otherwise, CodePulse falls back to PR-based proxies that approximate DORA metrics from GitHub data alone. The data source is always labeled so you know which one you are seeing.

Deployment Frequency

With deployments: Count of successful deployments to production in the period, sourced from the GitHub Deployments API.
PR proxy: Count of PRs merged to the default branch in the period. This is a reasonable proxy for teams that deploy on merge, the most common pattern in continuous delivery.

Lead Time for Changes

With deployments: Median time from first_commit_at to deployment.created_at. This covers the full pipeline from code to production.
PR proxy: Median time from first commit to merge (first_commit_at to merged_at). This measures delivery to the main branch rather than to production. This understates actual lead time but covers the portion the engineering team controls.

Change Failure Rate

Percentage of deployments that result in a failure status, rollback, or incident. Calculated from GitHub deployment status events. When deployment data is unavailable, CodePulse uses the rate of revert commits and hotfix branches as a proxy signal.

Mean Time to Recovery (MTTR)

With deployments: Average time from a failed deployment to the next successful deployment to the same environment.
PR proxy: Average time from a revert or hotfix PR being created to that PR being merged. This captures the code-level recovery time but not the full incident lifecycle.

"DORA metrics were designed for research across thousands of organizations, not to manage your specific team. Use them as diagnostic signals, not KPIs."

For a deeper dive into how to use DORA metrics without gaming them, see our complete DORA metrics guide.

Code Review Quality

CodePulse analyzes PR comment content to measure review culture health. Counting comments alone tells you nothing about whether reviews are thorough. Three signals are calculated per developer and rolled up per team.

Sentiment Analysis (VADER)

Each PR comment is scored using VADER (Valence Aware Dictionary and sEntiment Reasoner), a lexicon and rule-based sentiment analysis tool specifically tuned for social media text. VADER produces a compound score from -1.0 (most negative) to +1.0 (most positive), which CodePulse maps to four labels:

Constructive Ratio

Percentage of a developer's review comments classified as "constructive" or "positive" out of total classified comments. A high constructive ratio indicates a reviewer who provides helpful, growth-oriented feedback rather than terse dismissals.

Actionable Comment Ratio

Percentage of review comments that require action from the PR author. Comments are classified as actionable based on content analysis: requests for changes, specific suggestions, questions requiring answers, and code modification requests. A review that is 100% "LGTM" comments has 0% actionable ratio, which may indicate rubber-stamping.

These three signals work together. A team with high sentiment but low actionable ratio might be too agreeable. A team with high actionable ratio but negative sentiment might have a toxicity problem. See our code review culture guide for benchmarks and improvement strategies.

Risk Detection

CodePulse checks every PR against eight risk patterns. Each has a defined threshold and a severity rating (high, medium, or low). No composite "risk scores," no hidden weightings. A PR either triggers a specific risk or it does not.

Each detection rule uses a single, documented threshold. There is no "risk score" that blends these factors into an unexplainable number. You can look at any flagged PR and immediately understand why it was flagged.

Knowledge Silos and Bus Factor

Knowledge silos are files that only one developer has touched during the analysis period. If that developer leaves, no one else has context on those files.

How Silos Are Detected

CodePulse identifies knowledge silos by counting the number of distinct PR authors per file across merged PRs in the selected time window. A file qualifies as a silo when:

• Exactly one developer has authored all merged PRs touching that file
• The file has been touched in at least 3 PRs (configurable via min_touches), so one-off changes do not count
• Test files and dependency files are excluded by default (configurable), since narrow ownership on those is expected

What the Dashboard Shows

For each detected silo, CodePulse shows the filename, the sole contributor, the number of PRs they authored touching that file, total lines changed, and the last modification date. Files are grouped by repository.

Bus factor for a repository comes from the ratio of single-contributor files to total actively maintained files. A repository where 80% of files are silos is riskier than one where 20% are.

For strategies on reducing knowledge concentration, see our code hotspots and knowledge silos guide.

File Hotspots

File hotspots are the most frequently changed files in each repository. High-churn files are refactoring candidates. They accumulate complexity, cause more merge conflicts, and often point to design problems that force repeated modifications.

Calculation

For each repository, CodePulse counts the number of distinct PRs that touch each file during the analysis period, plus the total lines added and deleted. Files are ranked by distinct PR count (not total lines) because frequency of change is a stronger signal of instability than the volume of any single change.

The top 10 files per repository are surfaced as hotspots. Both merged PRs and actively open PRs are included, so you can see files that are currently under heavy modification in addition to historical patterns.

Why This Matters

A file touched by 15 PRs in 30 days is telling you something. Maybe it is a shared utility that needs to be split. Maybe it is an integration point where teams keep stepping on each other. Maybe it is a configuration file that should be managed differently. The hotspot data does not tell you what to do, but it tells you exactly where to look.

Data Filtering and Exclusions

Raw GitHub data includes noise that distorts metrics. CodePulse applies several filters by default. All are documented, and most are configurable.

Bot Filtering

Developers are classified as bots when their GitHub login contains [bot] or matches a known bot account list (Dependabot, Renovate, GitHub Actions, etc.). Bot PRs are excluded from all metrics by default. This is togglable per API request.

Branch Exclusions

PRs from release branches, version tags (GA, RC patterns), and environment branches (main, master, staging, production, etc.) are excluded from cycle time and throughput calculations. These are operational merges, not feature development work. Including them would inflate velocity metrics.

Churn Calculation Exclusions

Code churn (lines modified then modified again in the same PR) excludes merge commits. Merge commits are identified by message patterns: "merge branch," "merge pull request," "merge remote-tracking," "merge tag," and "merge origin." Without this exclusion, merge conflict resolution would count as churn, which misrepresents actual rework.

Working Hours

When an organization configures working days, all duration-based metrics (cycle time, time to first review, review time, merge time) use working hours only. Weekends and configured holidays are excluded so they do not distort time-based metrics.

What We Deliberately Do Not Measure

What a tool chooses not to measure tells you about its values. CodePulse skips several metrics that other tools promote, because we think they do more harm than good.

Lines of Code

We track lines changed per PR and per developer for context (PR size, review effort), but we do not present lines of code as a productivity metric. LoC is too easy to game: auto-generated code, verbose formatting, and copy-paste inflation all produce big numbers. A developer who deletes 500 lines of dead code and adds 20 lines of clean abstraction has done more valuable work than one who added 520 lines of boilerplate.

Individual "Productivity Scores"

CodePulse does not compute a single productivity number for individual developers. The McKinsey "developer productivity" framework and similar tools that produce individual scores end up as surveillance tools that optimize for appearance over substance. Individual productivity scores harm team dynamics, discourage collaboration, and incentivize gaming.

"When a measure becomes a target, it ceases to be a good measure." -- Goodhart's Law

CodePulse provides per-developer metrics (cycle time, review load, sentiment) as diagnostic tools for 1:1 conversations, not as rankings or scores. The team performance measurement guide explains our approach in detail.

Commit Count

Commits per day is tracked but de-emphasized. Commit frequency reflects workflow preferences (squash vs. granular commits) more than productivity. A developer who makes 3 well-structured commits per day is not less productive than one who makes 30 micro-commits.

Story Points or Velocity

CodePulse does not ingest or calculate story point velocity. Story points are team estimates, not measurements. Comparing story point velocity across teams or over time conflates estimation accuracy with delivery performance. We focus on measurable outcomes: merged PRs, cycle time, and review coverage.

Metric Calculation Periods

Every metric is calculated across six time periods at once: daily, weekly (7 days), monthly (30 days), quarterly (90 days), biannual (180 days), and yearly (365 days). Each period is a rolling window ending at the current date.

Metrics are stored as snapshots with explicit period_start and period_end dates, so historical trends show how the metric evolved over time rather than just the current value. This is how CodePulse can show you that your cycle time improved from 48 hours three months ago to 24 hours today.

Metric calculation runs every 30 minutes via a background job. An incremental data sync runs every 15 minutes, and a full reconciliation sync runs daily at 2 AM UTC. Under normal operation, dashboard data is never more than 45 minutes stale.