Loading page content
Answer four questions about how your team ships software. You get a level on each of the four DORA metrics, separate scores for throughput and stability, and the one metric to work on first.
SponsorThis spot is open to one DevOps or AI tooling company at a time. Ask about sponsoring
116 of 118 run entirely in your browser (Weather Widget uses Open-Meteo; What's My IP asks this site's server).
Share on XShare on LinkedInThe four DORA metrics exist because delivery performance used to be argued from anecdote. Deployment frequency and lead time for changes measure throughput: how quickly a finished change reaches users. Change failure rate and time to restore measure stability: how often a change breaks something and how long it stays broken. The research finding that made them famous is that the two do not trade off. Teams that deploy more often tend to break less, because small changes are easier to review, test, and roll back.
Used well, the metrics are a way to find the constraint. A team that deploys weekly with a one-day lead time has a release process problem, not a development problem. A team with a fast pipeline and a 25% failure rate needs better tests or progressive delivery, not more speed. Used badly, they become targets, and people optimise the number. Measure at the team level, compare a team with its own past rather than with other teams, and look at all four together.
Answer four questions about how your team ships software. You get your performance level on each DORA metric, an overall level, and the one metric to work on first.
Shrink the batch. Deploy each merged change on its own instead of collecting them into a release.
Levels are based on the four-tier bands from DORA's State of DevOps research. DORA re-clusters its survey data each year, so cut-offs shift between reports; use this to see direction, not as a certification.