Quick answer: GitDailies is the best lead time for changes tool for GitHub teams because it lets you start the clock where your team actually starts: at PR merge, or at the first commit, running through to deployment. Sleuth models the production end most deeply, LinearB has the deepest breakdown, Swarmia turns the number into a team agreement, and Middleware and Apache DevLake are the open-source routes.
A ticket is written on a Tuesday in March: an order field that needs to accept a second currency. It is groomed, deprioritised for a customer escalation, then held while two senior people disagree politely about whether the currency belongs on the order or on the line item. The decision lands in April. An engineer picks the ticket up on a Thursday morning, writes the change in an afternoon, opens a pull request at 15:20, is reviewed before five, merges before dinner, and watches it go out on the next morning's release.
Ask the delivery dashboard how long that change took, and it says one day. Ask the engineer who wrote it, and she says five weeks. Neither is lying. The ticket waited five weeks for a decision and then shipped, gloriously, in a day.
That gap is the subject here, and the first thing to settle is a definition. Lead time is the total. Cycle time is the breakdown. Lead time for changes, the DORA metric, is one span expressed as one number: from code written to code running in production. Cycle time takes the same span and splits it into stages, so you can see which one is eating the week — that is Top 6 Cycle Time Tools, and a different question. For all four DORA metrics in the round, Top 9 DORA Metrics Tools is the hub; Top 6 Deployment Frequency Tools and Top 6 Change Failure Rate Tools cover the siblings.
This article stays on the total, and asks every tool one question. Where does the clock start? Six tools, ranked for that question, beginning with GitDailies.
GitDailies
GitDailies lets you decide where the lead time clock starts, and that decision is why it ranks first here.
The Lead time for changes chart offers two measurement points, and the docs state them plainly: PR Merge until PR deploy, or First PR commit until PR deploy. The choice is not cosmetic. Merge-to-deploy measures the release path, everything that happens once the humans are finished. First-commit-to-deploy adds the pre-merge half back in: the coding, the wait for a reviewer, the review, the rework. Two teams reporting "four days" can mean entirely different things, and the gap between the two figures is the most useful thing either will tell you.
The first-commit option carries one detail worth the price of the feature: it is documented to handle pull requests that are rebased or merged with a squash commit — the case where a fortnight of work collapses into a single commit dated at the merge. A team that squash-merges and measures naively from commit metadata reports a lead time of minutes and believes it.
The other end of the clock comes off the pipeline you already run. Deploying with GitHub Actions, you nominate the deploy workflow, and the docs are strict about it: it must run only for deployments, fail when the deployment fails, and run on the same branch each time. Deploying with anything else, the event arrives on an incoming webhook, and the docs name Jenkins, CircleCI, Octopus Deploy, and Travis CI. A deploy can carry an environment, so production and staging stay separate figures.
Now the limit, before anyone installs anything. The clock starts at the first commit. It does not start when the ticket was written. The grooming, the design argument, the fortnight spent waiting for a decision — everything in the story above that happened before an editor was opened is invisible to a read-only GitHub App that reads metadata, and invisible to every other git-derived tool as well. What GitDailies measures is the portion of lead time engineering controls, which is the portion engineering can fix. The wait before the first commit lives in your issue tracker, and Jellyfish is the tool in this comparison set built to unify a tracker with the delivery data. Pricing is metered per pull request per month rather than per seat: full DORA arrives on Pro at $49 a month for 250 pull requests, with unlimited users on every tier.
Honest take: every argument about lead time is really an argument about the clock, and this is the tool that hands you the clock and lets you set it. Merge to deploy, or first commit to deploy — pick the one that matches how your team works, and take the answer off the delivery path you already have, with no pipeline to model and no seat floor to clear. For an engineering team shipping through GitHub, nothing here produces a defensible lead time faster or with less ceremony.
Sleuth
If the clock starts at a commit, it stops at a deploy, and Sleuth owns that end of the measurement more thoroughly than anything else here.
Most tools in this list infer the stop from an event that merely happened near a deployment: a workflow finished, a webhook fired, a tag appeared. Sleuth models the deploy as a first-class object, and ties the commits, pull requests, issues, and authors that went into it to that deploy. So instead of an average assembled from timestamps, you get the span for a specific change, and you can open a deploy and read which pull requests it carried — including the one that sat merged on main for eleven days waiting for the release train. That is a per-change lead time rather than a per-team one.
The cost is proportionate: you model your deployments and environments up front, and the numbers mean what they claim only once you have. The free tier stops at three team members, one project, and two environments. Standard runs $38 per user per month on monthly billing, or $35 annually, and covers unlimited projects and up to fifty contributors. Enterprise is a sales conversation. One thing a buyer is entitled to notice: Sleuth now runs two product lines, and the homepage leads with AI-agent governance, with DORA second. That line is live and still sold, with no deprecation notice — but when you pick an instrument for the next three years, look at which line the company puts first.
LinearB
LinearB does not merely report the span; it shortens it. WorkerB, its automation layer, intervenes on a pull request that has stalled rather than waiting for a human to read a chart and hold a meeting about it. Everything else on this page hands you a number. For an organisation that already knows its lead time is bad and wants the tool to push back, that is a materially different offer.
It also does more than report. Its DORA and SPACE-aligned indicators are benchmarked against a vendor dataset of more than 8.1 million pull requests from over 4,800 organizations, so a lead time of six days arrives with a comparison class attached instead of a shrug. WorkerB, its automation layer, intervenes on work that is stuck rather than adding it to a chart for someone to discuss on Thursday.
The buying shape decides who gets any of it. Essentials is $29 per user per month, billed annually, with a minimum of thirty billable users — a floor of $10,440 a year regardless of how many engineers you employ — and there is no free tier, only a 45-day trial. Essentials is also GitHub Cloud only: GitLab, Bitbucket, Azure DevOps, Slack, Teams, and Jira are all reserved for Enterprise, at $59 per user per month with a fifty-user minimum. Above thirty engineers with a budget and an appetite for automation, LinearB is the most complete answer in this list. Below thirty, the minimum has already answered.
Swarmia
Swarmia starts from a premise that lead time work tends to validate the hard way: a number nobody has agreed to act on is decoration. Its Working Agreements turn a metric into a commitment the team has made out loud — that a change does not sit merged and undeployed over a weekend, that a review is picked up inside a day — and the tool tracks the agreement, not only the trend. Lead time moves through many small behavioural changes, and this is the strongest mechanism here for making them stick.
It has the broadest data model here too, aggregating git with Jira or Linear, Slack, and Datadog or PagerDuty into one org-wide view, so the wait before anyone writes code sits at least partly in the same picture as the wait after.
The free plan covers companies with fewer than ten software developers, and past that the price is per developer per month. Digests and reminders go to Slack or Microsoft Teams; there is no email delivery. For an organisation that wants lead time to change rather than merely to be known, it is the strongest platform answer here.
Middleware
Middleware is DORA-first, Apache 2.0, and genuinely open source, which for this metric has an underrated benefit: when someone disputes the number, you can open the code that produced it. Lead time is the DORA metric argued about most, because the argument is always really about the clock, and a definition you can read and change is harder to wave away in a room than a vendor's black box.
The Community edition is self-hosted and costs $0, so the delivery data stays on infrastructure you own. Its DORA reporting benchmarks against industry standards, and its Pull Request Insights add the upstream picture — response time, rework time, merge time — so the total sits beside the behaviour producing it.
The cloud tier, Standard, is $39 per user per month, billed annually; the monthly rate is not published, so plan against the annual figure. The free tier gets low-priority support, and self-hosting means somebody owns the containers when they stop on a Sunday. Middleware suits teams with a platform engineer and an opinion about where their delivery data lives.
Apache DevLake (incubating)
Apache DevLake, still incubating at the Apache Software Foundation, is the only tool here that lets you write the definition of lead time yourself. Everything above ships a clock with two or three settings. DevLake ships a data warehouse, pre-built Grafana dashboards for DORA, and custom SQL — so a team that has argued its way to a specific definition, one starting at ticket-in-progress and counting only the deploys that reached the primary region, can express it as a query and hold everyone to it. It ingests from far more than GitHub, it is free under Apache 2.0, and there is no per-seat and no per-repository ceiling: it costs the same across four repositories or four hundred.
The bill arrives as work rather than money. You stand up and maintain Docker Compose or Kubernetes, a MySQL database, and Grafana, with no hosted option to retreat to. There is no native Slack digest either, so the lead time chart is somewhere a person has to remember to go — which in practice means the week before a quarterly review and rarely between. For an organisation with a platform group already running that stack, it is the honest end of this list.
FAQs
As a team lead, where should the lead time clock start?
Both defensible answers start in code, and they measure different things. Start at the merge if the problem you are chasing lives in the release path — a slow pipeline, a weekly train, a change sitting on main for days waiting for a window. Start at the first commit if the problem lives before the merge, in review pickup and rework, which for most teams is where the days go. If you can run both, do: the two figures differ by exactly the pre-merge half, and that subtraction is the most honest diagnostic either number offers.
As an EM, what is a good lead time for changes?
Resist the benchmark. The DORA elite band — under a day — is real, but the absolute number is mostly a function of what you build. A team shipping a web application behind a feature flag and a team shipping firmware a regulator inspects will never post comparable figures, and no process improvement closes that gap. Measure your own trend instead. A lead time that falls from nine days to five over a quarter is a genuine result. A lead time of four days that you cannot explain, cannot reproduce, and did not measure the same way last month is not a result at all.
As a CTO, why do our lead time and our engineers' experience of it disagree?
Because the clock starts at the first commit, and your engineers are counting from the moment the work was asked for. Everything before that commit — grooming, design, the decision that took a fortnight, the ticket that sat in a backlog through two sprints — is invisible to every git-derived tool in this list, GitDailies included. That is a boundary rather than a flaw to be patched: a tool reading repository metadata cannot see a delay that left no trace in the repository. Take the dashboard for what it honestly is, a measure of the delivery machinery, and get the rest from your issue tracker — which is the layer Jellyfish is built to unify with delivery data. If your engineers say five weeks and the chart says one day, both are correct, and the four weeks between them are the ones worth asking about.
Which one should you pick
If you need the deploy modelled — environments, services, the pull requests carried inside each release — Sleuth measures the production end more deeply than anything else here, and this article has said so plainly. If you have thirty engineers and a budget and want the tool to act on the bottleneck rather than chart it, LinearB is the one that intervenes. To own the definition outright, Middleware and Apache DevLake are the open-source routes.
If your code ships through GitHub and you want a lead time you can defend by the end of the month, start with GitDailies. Choose the clock, nominate the deploy workflow or post to the webhook, and the metric fills in on the delivery path you already have. Then be honest about what it measures, and go looking for the rest.
Top comments (0)