How It Works
How DeployMeter measures AI-assisted delivery — from PR analysis to DORA metrics.
Overview
DeployMeter measures how much faster your team ships with AI assistance by comparing two numbers for every merged pull request: how long the change would take at a fixed, published pace without AI — the baseline — and how long it actually took, from commit activity or from measured coding time.
It also tracks DORA metrics (deployment frequency, lead time, change failure rate, failed deployment recovery time) from the deployments you tell us about, incidents from the sources you connect, and review flow — one picture of engineering performance, all from pull requests.
PR Analysis Pipeline
Branch strategy assumed
We assume a trunk-based or GitHub Flow model: feature branches are opened as PRs and merged directly into
main or master. Only merged PRs are analysed — open or closed-without-merge PRs are ignored.What we skip
Dependabot, Renovate, and other bot PRs
PRs closed without merging
PRs authored by GitHub Actions or [bot] accounts
Merge commits inside a PR (counted in parent PR instead)
Actual time
Actual coding time
We read the commits on the pull request branch and group them into work sessions. The time between sessions is ambiguous — a pause, or work that left no commit — so actual time is a band: the low end counts only the sessions, the high end also counts the gaps, each gap capped. The point we report sits between the two. Merge commits and rapid amend/fixup commits are excluded. With measured coding time from the git hooks the band collapses to a single measured value.
Single-commit pull requests
A pull request with a single commit has no gaps to measure. Its actual time is a wide band, from a minimal session up to one capped session, and it is marked estimated. Measured coding time from the git hooks replaces the band.Local Time Tracking (recommended)
Install git hooks per repo
For more accurate coding-time data, each developer should run the following command inside every tracked repository. It installs git hooks that capture branch switches, commits, and active coding sessions — then sends the data to DeployMeter on push.
npx deploymeter initInstalled hooks
post-checkout — records branch switches and starts a heartbeat for active coding detection
post-commit — records each commit with file stats
pre-push — sends all collected session data to DeployMeter
Baseline: DeployMeter Standard v1
The baseline is deterministic and versioned. Every file in the diff is classified by path and extension — logic, tests, schema, config, docs, generated — and each class has a fixed pace. The same diff gives the same baseline in every organization, and every analysis records the version of the ruler it used. Nothing in your settings changes it.
The model contributes only two bounded factors: how complex the change is, and what share of the logic is boilerplate. It never sets the amount of work, it is not shown commit timestamps, and lines rewritten within the pull request count at half.
The baseline is a band as well: complexity one level down and up, and the boilerplate share swapped for the model's lower and upper bounds. A docs-only pull request has a band of width zero.
Every pull request card shows the calculation line by line. If it is wrong, contest it there: the ruler is corrected for everyone, never overridden per organization.
AI Multiplier
The core metric
multiplier = baseline minutes ÷ actual minutesShown as a band whenever the actual time is a band: baseline low over actual high, and baseline high over actual low.
A multiplier of 3x means the change shipped in a third of the baseline time. Team and organization numbers are the median over at least 20 analyzed pull requests, shown with the P25–P75 range; below 20 the dashboard says so instead of showing a number. Time saved is winsorized so a single outlier cannot carry the total.
Deployment Tracking
DeployMeter tracks actual deployments to power accurate DORA metrics. You can choose how deployments are detected in Settings → Tracking.
PR Merge (default)
Every merged PR is treated as a deployment. Best for trunk-based development where merging to main automatically deploys.
GitHub Actions
Deployments are detected from your deploy workflow runs (e.g. deploy or release pipelines) — successful runs and failed ones alike, because a deploy that failed is still a change that was attempted. A failed run counts in the change failure rate; it only opens an incident when you give it a severity in Settings. Multiple PRs can be grouped into a single deployment. Requires the GitHub App to have Actions: Read permission and the workflow_run event subscription.
GitHub Deployments
Deployment status events for the environments you name (production by default). The only source that tells a failed CI run from a failed production deploy; covers Vercel, Heroku, Render and workflows with an environment.
External Webhook
External CI/CD tools (Jenkins, Octopus Deploy, etc.) send deployment notifications via a signed webhook. PRs merged since the last deployment are automatically grouped.
Configuration
Go to Settings → Tracking → Deployment Detection to choose your mode and configure workflow patterns or webhook secrets.DORA Metrics
We track the four DORA metrics using deployment records. The deployment detection mode (configurable in Settings) determines how deployments are counted.
Deployment Frequency
Number of successful deployments per day, whichever detection mode you use. In PR Merge mode each merged PR counts as one deployment; in GitHub Actions, GitHub Deployments or Webhook mode they come from actual deploy events.
Lead Time for Changes
Median hours from the first non-merge commit to production (or to merge when the repository has no deploy pipeline).
Change Failure Rate
Share of deployments — all outcomes, not only the successful ones — that failed, or had an incident attributed to them (inferred and then confirmed or rejected by you). Incidents with no deployment attributed stay out of this number. A deployment flagged by more than one source counts once.
Failed Deployment Recovery Time (FDRT)
Median time to recover the deployments counted in the failure rate, from the failure or the incident opening to the fix. Renamed from MTTR per DORA 2025.
Incidents & Uptime
Where incidents come from
Incidents come from the sources you connect: GitHub issues carrying your incident label or issue type, PagerDuty, Opsgenie or custom webhooks — and, only if you give it a severity in Settings, a failed workflow or a failed production deployment. A failed deploy on its own counts in the failure rate, not as an incident. Revert and hotfix detection proposes candidates that count only once you confirm them on the Incidents page.
How to connect an incident source
- Go to Settings → Tracking → Incident sources
- Turn on the sources you use: the GitHub issue label or issue type, the incident webhook, and optionally a severity for failed deploys
- Point PagerDuty, Opsgenie or your own tooling at the webhook URL with the generated secret, or set the label your team already puts on incident issues
- Review the revert and hotfix candidates on the Incidents page — a confirmed one counts towards the metrics, a dismissed one never does
Uptime
Uptime is the share of the selected period without an open incident at or above the severity you set as downtime — SEV1 only by default. Incidents without a severity never count as downtime. It is a proxy for availability, not a monitoring feed, and it has no industry rating.
For Accurate Results
Developers should commit to their branch regularly, not squash everything into one commit at the end
Keep PRs focused — large multi-week PRs underestimate the multiplier
Weekend and off-hours commits are counted correctly (no business-hours filter)
Protect your main branch — require pull requests and disable direct pushes so every change is tracked correctly
Run npx deploymeter init in each repo so every developer gets precise coding-time tracking via git hooks
Create a free account to see the full calculation on every pull request.
Get started