Every metric, measured where it actually happens.
Throughline reads your Git history, pull request events, and CI pipelines and turns them into four delivery signals — cycle time, deploy frequency, PR throughput, and lead time. No instrumentation, no story points, no spreadsheets. The data is already there; Throughline just makes it legible.
Read-only access · Connects in minutes · SOC 2 Type II
What each metric measures, and how Throughline computes it.
Each signal is derived from timestamped events — commits, PR state changes, pipeline runs, deploy hooks. Nothing is estimated or self-reported.
How long it takes from first commit to merge.
Cycle time is measured from the first commit on a branch to the moment that branch is merged. It captures real coding effort plus all the waiting in between — for review, for CI, for a second look. When cycle time rises, something upstream is blocking flow.
- → Source: Git push and merge timestamps
- → Excludes weekends and configurable off-hours
- → Lower is better — improvement shows as a downward trend
How often your team ships to production.
Deploy frequency counts successful production deploys per day. High-frequency teams catch regressions sooner, reduce blast radius, and move faster because each change is smaller. Throughline reads deploy events directly from your CI provider — no webhooks to configure manually.
- → Source: GitHub Actions, CircleCI, Jenkins, and Buildkite pipeline events
- → Filters to production environment only — staging runs excluded
- → Higher is better — improvement shows as an upward trend
How many pull requests your team merges per week.
PR throughput is a direct read of team output. A sudden drop often signals a process problem — a long-running PR blocking others, a review queue that isn't moving, or a branch strategy that forces serialization. Throughline tracks it per team, per author, and per repo.
- → Source: PR merge events from GitHub, GitLab, or Bitbucket
- → Broken down by author, team, and repository
- → Higher is better — improvement shows as an upward trend
From commit to production, end to end.
Lead time measures the full span from a commit's first push to its arrival in production. Where cycle time ends at merge, lead time captures everything after — deploy queues, staged rollouts, manual gates. Together they show you which half of delivery to focus on.
- → Source: first push timestamp to successful production deploy event
- → Compared to cycle time to expose post-merge lag
- → Lower is better — improvement shows as a downward trend
Every stage, timed. The worst one, flagged automatically.
Throughline breaks each change into four stages and computes p50 and p95 for each. When one stage accounts for a disproportionate share of total cycle time, it gets flagged — so you know where to intervene without guessing.
Stage-level timing at every percentile.
Median (p50) tells you what's normal. The 95th percentile tells you what the worst outliers experience — and it's usually the p95 that's blocking your team's confidence in deploying. Throughline shows both, side by side, for each stage in the delivery pipeline.
When a stage's p95 is more than 3× its p50, Throughline raises a flag. Review wait currently runs at 4.6× — that's why it's marked.
From the flagged row, click through to see the individual PRs that contributed to the p95. Filter by author, team, or date range. Export the list to share in a retro.
| Stage | p50 | p95 | Share |
|---|---|---|---|
| Coding | 2.1h | 6.4h | 24% |
| Review wait Flagged | 3.1h | 14.2h | 82% |
| CI & checks | 11m | 24m | 14% |
| Deploy to prod | 18m | 1.2h | 30% |
Review wait is 5.8× your median coding time. Throughline flags it automatically and links to the PRs that drove the p95.
Connects to the stack you already run.
Read-only OAuth access — no agents, no webhooks to configure, no infrastructure to maintain. Throughline connects in minutes and starts computing metrics from your existing history.
Code hosting
CI & pipelines
Read-only by design.
Throughline requests read access only — it never writes to your repositories, triggers pipelines, or modifies code review state. Your security team can verify the OAuth scope list before you connect.
Live in under five minutes.
OAuth connect, pick your repos, choose your team boundaries. Throughline backfills up to 12 months of history on first sync. Metrics are available before your next standup.
Built for engineering leads who run multiple teams.
The four signals are the core. These are the features that make Throughline the tool you keep open — not just the one you check before a quarterly review.
Baselines and comparisons.
Every metric is benchmarked against your own rolling 90-day baseline, not a vendor-defined "elite" threshold. You know what your team has achieved — Throughline shows whether you're above or below it.
Per-team and org rollups.
Define team boundaries around the repos and people that match your org chart. Drill into a single team or roll up to org-wide. VPs of Eng see aggregate health; leads see their team's detail.
Threshold alerts.
Set a threshold on any metric — cycle time above 8h, deploy frequency below 4/d — and get a Slack or email alert when the 7-day rolling average crosses it. No dashboards to watch.
Incident and freeze annotations.
Mark incidents, code freezes, and major releases directly on the timeline. When a metric spikes, the annotation tells the story — so the chart survives a board review without a paragraph of explanation.
One-click export to slides and Slack.
Export any chart or table as a ready-to-present slide, or send a formatted weekly digest to a Slack channel. Delivery reviews no longer require someone to manually copy numbers out of a dashboard on Friday afternoon.
API access.
Every metric Throughline computes is available via a REST API. Pull delivery data into your internal tooling, pipe it into a data warehouse, or use it to power a custom engineering effectiveness dashboard.
Read the API docsSee your real cycle time before the call ends.
Book a 30-minute demo. We'll connect a repo live and show you your team's four delivery signals — no slides, no pitch deck, no made-up benchmarks.