blinkx analytics

Tools

Free and Open-Source DORA Tooling: What Actually Works in 2026

You can run DORA metrics without paying a vendor. Here's what's available, what each option costs you in engineering time, and when free stops being cheaper.

You do not need to buy a platform to get DORA metrics. Deployment frequency and lead time are derivable from data your CI system and git history already hold, and there is a mature open-source stack for the rest.

What free costs you is engineering time. This piece covers what's available, what each option demands, and the point where paying becomes the cheaper option.

What are the options?

Apache DevLake (Incubating) is the leading self-hosted choice. It ingests data from across a toolchain — GitHub, GitLab, Jira, Jenkins, BitBucket, Azure DevOps, PagerDuty and dozens more — into a unified data lake and ships pre-built DORA dashboards via Grafana. Because it's fully open, teams can define their own deployment and incident logic, write custom SQL, and extend dashboards to match how they actually release.

It's the only option that gives you complete ownership of how metrics are computed and stored. It also requires real infrastructure work: deployment via Docker Compose or Helm, database management, connection configuration and ongoing maintenance.

Four Keys comes from Google's DORA team. It collects events from GitHub or GitLab and calculates the four original metrics. Narrower than DevLake and correspondingly simpler.

Middleware and Dorametrix are lighter open-source options — the latter a serverless service that infers metrics from webhook events.

OpenDORA provides a Backstage plugin for surfacing DORA metrics in a developer portal.

What you may already be paying for: GitLab has a Value Streams Dashboard. Datadog has a DORA Metrics module that integrates with your CI/CD pipeline and correlates against infrastructure data. GitHub Insights covers part of lead time. If any of these are already in your stack, start there before deploying anything.

What's the catch with the free stack?

Change failure rate needs incident data, and that's where free breaks down.

Deployment frequency and lead time come out of systems you already run. Change failure rate and recovery time require knowing which deployments caused problems and when service was restored — which means incident management. PagerDuty is the most common source, precisely because its incident timelines record start, escalation and resolution with enough precision to compute recovery time reliably. It integrates natively with DevLake, GitLab's Value Streams Dashboard and Datadog's DORA module.

PagerDuty is not free, and it is not a DORA tool — it's an incident platform that happens to be the best available source for two of the five metrics. Teams that skip this step end up with two solid metrics and two they've quietly estimated.

Nobody looks at Grafana. This is the failure mode that kills most self-hosted deployments. The platform team stands up DevLake, builds dashboards, writes per-team SQL filters, wires Grafana to SSO — and then discovers developers don't open Grafana. The historical fix was embedding iframes or building a custom Backstage plugin, which is more maintenance surface.

That got easier in 2026. A DevLake-to-DORA backend module contributed to Backstage's community-plugins repository bridges DevLake's metrics API into Backstage's standard DORA plugin and adds a card showing deployment frequency, lead time, change failure rate and failed deployment recovery time on every service's catalog page. The metrics wiring platform teams used to build first is now the part they can skip.

Whether that helps depends on whether you run Backstage. Adoption is substantial — over 3,400 adopters, top five among CNCF projects by development velocity, and placed in the "Adopt" tier of the Q1 2026 CNCF Technology Radar for application delivery. Gartner's forecast that 80% of large engineering organisations would run platform teams by 2026, up from 45% in 2022, is the demand curve underneath it.

When does free stop being cheaper?

Four thresholds, in rough order of how often they're hit:

When you need the survey layer. Every open-source option measures system data. None of them handles developer experience surveys, which is the dimension that explains why your delivery numbers moved. If your measurement programme needs both, the open-source stack covers half of it.

When maintenance exceeds the licence cost. DevLake needs someone. Half a day a month is a reasonable steady state once it's running; standing it up is measured in weeks, not days. Price that against a per-seat quote before assuming free wins.

When you need cross-team comparison at scale. Custom SQL is fine for five teams. At fifty, the reporting layer is the product, and building it internally is a project with a roadmap.

When you need it in front of an executive next quarter. Self-hosted is the right call when you have platform capacity and time. It's the wrong call when the deadline is a board meeting.

What's the sensible starting point?

If you're at zero and want something running this month: DevLake for the metrics, whatever you already use for incidents, and a decision made in advance about where the numbers will be displayed. That last part is not an afterthought — it's the step that determines whether anyone uses what you built.

If you already pay for Datadog or GitLab Premium, activate what's included before deploying anything new. Teams routinely stand up a parallel stack for metrics they were already entitled to.

If you have no platform engineering capacity at all, the free stack isn't free. Get a quote and compare it honestly against the engineering hours.

Frequently asked

Can I get all five DORA metrics without paying anything? Deployment frequency, lead time and rework rate are achievable from free tooling. Change failure rate and failed deployment recovery time need incident data with reliable timestamps, which in most organisations means a paid incident platform.

Is DevLake production-ready? It's an Apache incubating project in wide use. The practical constraint is operational rather than functional: it needs owners, upgrades and a database.

Do open-source tools handle AI attribution? No. They operate on the same pipeline metadata as commercial platforms in that category, so they carry the same architectural limit.

What's the fastest path to a first number? Deployment frequency from your CI system, computed manually for one team over the last quarter. It takes an afternoon and often reveals enough to make the tooling decision better informed.