Wat zijn DORA metrics? Vier kernmetingen voor releases

Wat zijn DORA metrics? Simpel gezegd: vier metingen die de prestatie van softwarelevering kwantificeren. Deployment Frequency, Lead Time for Changes, Change Failure Rate en Time to Restore Service. Ontwikkeld door Nicole Forsgren, Jez Humble en Gene Kim, gevalideerd op tienduizenden engineeringteams, en in 2018 overgenomen door Google. Deze gids legt uit wat elke metric volgt, hoe de benchmarks er in de praktijk uitzien, en waar dit raamwerk aan grenzen stuit.

Waar DORA metrics vandaan komen en waarom het onderzoek ertoe doet

Het DORA-programma begon in 2014 met een concrete vraag: wat doen high-performing softwareteams anders dan iedereen? Het onderzoeksteam voerde jaarlijkse enquetes uit onder tienduizenden developers in verschillende industrieen, op zoek naar praktijken die sterke leveringsresultaten voorspelden.

De bevinding die het onderzoek voeding gaf, was contra-intuitief. Elite-teams ruilen geen snelheid in voor stabiliteit. Ze leverden sneller en hadden minder productieproblemen. Dit ondermijnde de standaardredenering om releasecycli te vertragen: als we minder vaak deployen, breken we minder dingen.

De data zei het tegendeel. Teams die frequent deployeden, bouwden betere feedbackloops, onderschepten problemen eerder en herstelden sneller wanneer iets foutging. Snelheid en stabiliteit waren niet tegengesteld. Ze waren gecorreleerd.

Google nam het DORA-programma in 2018 over. Het team publiceert nu jaarlijks een State of DevOps Report, heeft het model in 2025 uitgebreid met een vijfde metric (Rework Rate), en onderhoudt het onderzoek als open initiatief op dora.dev.

De vier metingen en wat ze werkelijk meten

Het model werd in 2025 bijgewerkt met Rework Rate als vijfde metric, maar de vier originele kernmetingen blijven de baseline voor meeste tooling en teamdiscussies.

Deployment Frequency

Hoe vaak deployt jouw team naar productie. Dat is de volledige definitie.

Elite-teams deployen on-demand: meerdere keren per dag als iets klaar is. Laagpresteerders deployen eenmaal per maand of minder, soms eenmaal per kwartaal. Voor een solo-developer betekent een consistent wekelijks releasetempo dat je al in de high-performing bracket zit op basis van deze meting alleen.

Deployment frequency is een proxy voor pipelinezekerheid. Teams die zelden deployen, hebben meestal fragiele infrastructuur, zware handmatige teststappen of organisatorische goedkeuringsketen die releases afremmen. Teams die meerdere keren daags livegaan, hebben de meeste bottlenecks geautomatiseerd. De frequentie is een symptoom, niet de oorzaak.

Lead Time for Changes

De tijd van een commit in versiebeheer tot diezelfde change live in productie.

Het meeste van deze duur is niet coderen. Het is wachten: wachten tot de pull request-wachtrij opbouwt, wachten tot CI/CD-pipelines klaar zijn, wachten op een deploymentsslot, wachten tot iemand met toegang de release triggert. Een lead time van enkele uren betekent dat de workflow strak en grotendeels geautomatiseerd is. Een lead time gemeten in weken betekent dat iets structureels friction toevoegt op een of meer overdrachtsposten.

Voor solo-developers is lead time wat tussen het pushen van een commit en gebruikers die het zien staat. Soms een deploypipeline die twaalf minuten duurt. Soms interne twijfel over of een change stabiel genoeg is om live te gaan.

Change Failure Rate

Het percentage deployments dat een probleem veroorzaakt ernstig genoeg voor een hotfix, rollback of incidentrespons.

Dit is het kwaliteitssignaal in het DORA-model. De 2024 State of DevOps Report plaatst elite-teams rond 5% change failure rate. Laagpresteerders draaien op 46-63%. Als ruwweg de helft van je deployments onmiddellijke interventie vereist, hebben je testdekking en reviewproces ernstige gaten.

Change failure rate meet geen coderingskwaliteit in abstracto. Het meet of de changes die je deployt zich gedragen zoals verwacht in de productieomgeving specifiek. Een testsuites die lokaal slaagt maar de integratiepatronen niet afdekt die in productie falen, verplaatst dit getal niet.

Time to Restore Service

Wanneer een deployment een incident veroorzaakt, hoe lang tot service hersteld is?

Dit werd oorspronkelijk Mean Time to Recovery (MTTR) genoemd. Het DORA-team actualiseerde de formulering in 2025 naar Failed Deployment Recovery Time, specifiek trackend recovery van deployment-veroorzaakte incidenten in plaats van infrastructuurfouten of third-party uitval. Het onderscheid telt omdat deployment-veroorzaakte incidenten volledig onder controle van het team liggen, waardoor ze het juiste doel voor procesverbetering zijn.

Elite-teams herstellen service in onder een uur. Laagpresteerders kunnen dagen tot weken nodig hebben. Als je solo-developer bent, gaat het bij deze metric vooral om of je monitoring hebt. Teams zonder alerting-infrastructuur krijgen van gebruikersklachten in plaats van geautomatiseerde signalen te weten wat fout is, wat uren toevoegt aan elke hersteeltijd.

Hoe de performancetiers er werkelijk uitzien

De State of DevOps report groepeert teams in vier tiers op basis van hun DORA-nummers. Dit zijn ruwe bereiken uit de 2024-report, niet harde afsnijdingen:

Performance tiers basés sur DORA metrics:

Elite: Meerdere keren per dag | Onder 1 uur | Onder 5% | Onder 1 uur

High: Dagelijks tot wekelijks | 1 dag tot 1 week | 5-10% | Onder 1 dag

Medium: Wekelijks tot maandelijks | 1 week tot 1 maand | 10-15% | 1 dag tot 1 week

Low: Maandelijks of minder | 1 tot 6 maanden | 46-63% | 1 week tot 6 maanden

De kloof tussen elite en low is niet incrementeel. Volgens de 2024-report kunnen laagpresterende teams meer dan 180 keer langer nodig hebben om te deployen en meer dan 2.500 keer langer om van incidenten te herstellen vergeleken met elite-teams. Dit zijn geen marginale verschillen.

Elite-tier bereiken is haalbaar met blijvende investeringen in CI/CD-automatisering, testdekking en observabiliteitstools. Het gebeurt niet door sneller code te schrijven. Het gebeurt door handmatige stappen en wachttijden tussen het committen van code en het betrouwbaar runnen ervan in productie te verwijderen.

Hoe AI-hulpmiddelen DORA-cijfers in 2026 verschuiven

Tegen 2026 zijn AI-codeertools gemeenschappelijk genoeg om DORA-metingen op manieren te beinvloeden die specifiek volgen waard zijn.

Teams die Cursor, GitHub Copilot of vergelijkbare tools gebruiken, schrijven code sneller, wat deployment frequency doorgaans omhoog duwt. Lead time is ook bij veel teams korter geworden omdat meer code per developer per week geproduceerd wordt, wat meer commits door de pipeline betekent.

Change failure rate is beide kanten opgegaan. Teams met sterke reviewprocessen en testdekking hebben hun faalpercentages stabiel gehouden terwijl ze meer leverden. Teams die AI-gegenereerde code zonder adequate review deployen, hebben stijgende faalpercentages gezien. Het DORA-model geeft niet om hoe code geschreven wordt. Het meet wat na deployment naar productie gebeurt.

De DORA 2024 State of DevOps Report vond dat 41% van ondervraagde teams rapporteerde AI-ondersteunde ontwikkelingshulpmiddelen te gebruiken. Die teams toonden hogere deployment frequency zonder proportionele stijging in change failure rate wanneer AI-adoptie gekoppeld was aan geautomatiseerde test- en reviewpipelines.

Hier ligt de rub in praktijk: AI versnelt het frontgedeelte van de pipeline aanzienlijk. DORA vertelt je of die versnelling schoon wordt geabsorbeerd of instabiliteit stroomafwaarts creert.

Tools voor het volgen van DORA-metingen zonder je stack overdreven uit te breiden

De meeste teams beginnen DORA-metingen te meten door data te trekken uit tools die ze al gebruiken: GitHub of GitLab voor deploymentgebeurtenissen en commit-timestamps, PagerDuty of OpsGenie voor hersteeltijd data, en het incidentbeheersysteem voor change failure rate tellingen.

Diverse platforms hebben DORA-dashboards gebouwd specifiek rond deze vier metingen:

Voor een solo-builder zonder toolbudget: een script dat de timestamp van elke productiedeployment en elk herstelgebeuren registreert geeft je deployment frequency en hersteeltijd zonder infrastructuurkosten. Lead time kan benaderd worden uit commit-timestamps in de Git-log.

Waar DORA-metingen werkelijk grenzen hebben

DORA meten is nuttig. Het als het volledige beeld van engineeringprestatie behandelen creert verschillende blinde vlekken waard om te noemen.

Technische schuld ophoping. Hoge deployment frequency met lage change failure rate vertelt niets over of de codebase in de loop van de tijd moeilijker werkt. Een team kan elite DORA-nummers bereiken terwijl gestaag technische schuld opstapelt die elke nieuwe feature langer duurt. DORA meet deliveryoutput; het meet niet de staat van wat je levert.

Outcome alignment. Deployment frequency meet output, niet outcomes. Vijf keer per dag leveren maakt niet uit als geen van die changes een metric verplaatst waar het product of de zaken om geven. Feature flags, A/B-testinfrastructuur en bedrijfsmetricstracking liggen volledig buiten het DORA-model.

Duurzaamheid. Het DORA-onderzoeksteam voegde een developer experience dimensie aan het raamwerk toe in 2023, erkennend dat duurzame hoogprestaties engineers vereist die niet op burnout draaien. De vier kernmetingen tracken niet of het bereiken van elite-nummers ergens anders een prijs kost.

Gebruik DORA als diagnostisch hulpmiddel, niet als scorebord. De vragen die de metingen oproepen, zijn vaak actiever dan de nummers zelf. Een change failure rate van 30% is minder bruikbaar dan weten welke soorten changes het vaakst falen en waarom.

Waar te beginnen als je dit nooit eerder hebt gemeten

Een zes maanden oud side project zonder DORA-data is normaal. De meeste kleine teams en solo-builders hebben dit nooit gemeten.

Als je van nul begint, kies eerst deployment frequency en lead time. Beide zijn gemakkelijk uit te trekken uit Git commit-timestamps en deployment-logs, en geven je onmiddellijke terugkoppeling over of je pipeline onnodige friction heeft. Een lead time van drie dagen voor een change die veertig minuten duurt om te schrijven is een signaal waard onderzoeken.

Change failure rate en time to restore vereisen incidenten die zich ophopen voordat de nummers iets betekenen. Als iets in productie breekt, log de timestamp detectie en timestamp resolutie. Die data groeit in de loop van de tijd.

Een praktische gewoonte: na elk productieincident, stel twee vragen. Hoe lang duurde het voordat dit probleem werd opgemerkt? Hoe lang van detectie tot resolutie? Die twee nummers zijn de inputs naar time to restore. Ze consistent zes maanden volgen geeft je genoeg geschiedenis om te weten of je herstelproces verbetert of stationair blijft.

Drie redenen om DORA-metingen zelfs als solo-dev te meten, een reden om het niet te doen: de metingen maken onzichtbare friction zichtbaar, creren verantwoordingsplicht voor automatiseringsinvesteringen, en geven je iets concreets om tussen featurework te verbeteren. De reden om het niet te doen: als je pre-launch bent zonder echte productiegebruikers, betekenen de nummers nog niet veel. Begin te meten wanneer je regelmatig naar echte gebruikers verzendt.