DORA-Metriken 2026: Warum aus vier fünf wurden (und was die meisten Dashboards falsch machen)

Öffnen Sie irgendein Engineering-Dashboard, das DORA zu messen behauptet, und Sie sehen mit ziemlicher Sicherheit vier Kacheln: Deployment-Frequenz, Lead Time, Change Failure Rate und MTTR.

Drei dieser vier Bezeichnungen sind veraltet, und die Auswahl selbst ist unvollständig. DORA ist in der Forschung von 2024 auf fünf Metriken für Software-Delivery-Performance umgestiegen, hat eine davon bereits 2023 umbenannt und eine weitere in eine Kategorie verschoben, die die meisten Teams bis heute falsch einsortieren. Im Jahresrückblick 2025 formuliert DORA es unmissverständlich: “We have also officially evolved the four software delivery performance metrics into five metrics.”

Das ist keine Wortklauberei. Die Änderungen kodieren Erkenntnisse, die unmittelbar beeinflussen, wie Sie Ihre eigenen Zahlen lesen sollten — und eine davon existiert nur deshalb, weil Teams die falsche Art von Fehlern gemessen haben.

Die fünf Metriken, wie sie heute stehen

DORA gruppiert die fünf Metriken in zwei Faktoren: Durchsatz und Instabilität.

Durchsatz — wie Änderungen durch das System fließen

Instabilität — wie gut diese Deployments verlaufen

Zwei Dinge in dieser Tabelle überraschen alle, die die vier Keys vor Jahren gelernt haben.

Die Recovery-Zeit steht beim Durchsatz. Ein Jahrzehnt lang lebte sie auf der Stabilitätsseite, als Gegengewicht zur Geschwindigkeit. Heute gehört sie zu den Flussmaßen. Die Logik trägt, sobald man auf die Form der Zahlen schaut: Instabilität wird in Verhältnissen ausgedrückt — welcher Anteil Ihrer Deployments schiefgeht — während der Durchsatz die Zeit- und Mengenmaße dafür abdeckt, wie Änderungen in die Produktion gelangen. Die Erholung von einem fehlgeschlagenen Deployment ist selbst eine Änderung, die in die Produktion geht, nur unter maximalem Druck.

Es gibt eine Metrik, die die meisten Teams nie erfasst haben. Die Deployment Rework Rate ist die Neuzugängerin, und ihre Entstehungsgeschichte ist der interessanteste Teil der Forschung von 2024.

Warum eine fünfte Metrik nötig war

DORAs Forschende bemerkten, dass die Change Fail Rate still und leise zwei Aufgaben erfüllte. Sie sollte erfassen, wie oft Deployments schiefgehen — Teams nutzten sie aber zugleich als Stellvertreter dafür, wie viel Nacharbeit ein Team leisten muss.

Das ist nicht dasselbe, und die Vermischung verdeckt einen realen Fehlermodus. Ein Team kann eine respektable Change Fail Rate haben, während ein großer Teil seines Deployment-Volumens ungeplante Arbeit ist, die aus Vorfällen entsteht. Auf einem Vier-Metriken-Dashboard sieht dieses Team gut aus. Tatsächlich wird ein wachsender Anteil seiner Kapazität dafür verbraucht, die Produktion zu reparieren, statt Neues zu liefern.

Die Deployment Rework Rate trennt beides. Die Change Fail Rate fragt: Hat dieses Deployment etwas kaputtgemacht? Die Rework Rate fragt: War dieses Deployment nur nötig, weil bereits etwas kaputt war?

Wer je beobachtet hat, wie die Deployment-Frequenz eines Teams steigt und trotzdem niemand ein einziges neues Feature benennen kann, hat genau die Lücke gesehen, die diese Metrik schließt.

Die Umbenennung, die einen echten Messfehler behob

Bevor sich die Anzahl änderte, änderten sich die Definitionen. 2023 benannte DORA die lange als MTTR oder Time to Restore Service bekannte Metrik in Failed Deployment Recovery Time um.

Die Begründung war präzise. Die alten Definitionen unterschieden nicht zwischen:

• einem Ausfall, der durch eine von Ihnen deployte Änderung verursacht wurde, und
• einem Ausfall, der ganz andere Ursachen hat — eine ausgefallene Cloud-Region, eine Störung beim Anbieter, ein Problem im Rechenzentrum.

Das gehört zu verschiedenen Systemen. Das erste ist eine Eigenschaft Ihres Lieferprozesses, das zweite eine Eigenschaft Ihrer Infrastruktur und Ihres Glücks. Beides zusammenzumitteln ergab eine Zahl, die sich aus Gründen bewegte, die nichts mit der Arbeitsweise des Teams zu tun hatten — genau das, was man von einer Delivery-Metrik nicht will. Die Einengung auf Beeinträchtigungen, die durch eine Änderung an der Produktion verursacht wurden, brachte sie statistisch mit den übrigen Delivery-Metriken in Einklang.

Die praktische Konsequenz: Wenn die MTTR-Kachel Ihres Dashboards von jedem Vorfall in Ihrem Incident-Tracker gespeist wird, ist sie nicht die DORA-Metrik. Sie ist eine Mischung aus zwei verschiedenen Signalen, und man kann nicht sauber auf sie reagieren.

Der Mythos von “Reliability, der fünften Metrik”

Sie finden bis heute Artikel, Präsentationen und Anbieterseiten, die Reliability als fünfte DORA-Metrik bezeichnen. Diese Einordnung stammt aus DORAs eigenem Report von 2021 — und DORA hat sie inzwischen korrigiert.

Die Historie der Metriken hält fest, dass der Report von 2021 “inaccurately called the ‘reliability’ metric the ‘fifth metric’ when, in reality, ‘reliability’ is more a measure of operational performance than a measure of software delivery performance.”

Die Unterscheidung ist wichtig. Reliability, gemessen über Service Level Objectives, beschreibt, wie gut sich die Software für Nutzer verhält, sobald sie läuft. Software-Delivery-Performance beschreibt, wie gut Änderungen in die Produktion gelangen. Beides gehört ins DORA-Core-Modell, aber es sind verschiedene Konstrukte, und sie beantworten verschiedene Arbeit.

Beachten Sie auch, was das für die Prüfung der eigenen Dokumentation bedeutet: Die Vier-gegen-fünf-Verwirrung ist nicht nur ein Nachhinken der Branche. Selbst DORAs Core-Modell, das bewusst konservativ ist und — in DORAs Worten — “deliberately trails the research”, zeigt weiterhin die ältere Vierergruppierung. Die Guides und die aktuelle Forschung sind ihm voraus. Das ist Absicht, aber ein guter Grund, bei allem, was Sie lesen, auf das Datum zu schauen.

Messen, ohne eine Plattform zu kaufen

Sie brauchen keinen Anbieter, um anzufangen. Vier der fünf Metriken fallen aus Deployment-Ereignissen heraus; die fünfte braucht ein wenig menschliche Eingabe, die keine API für Sie ableiten kann.

Beginnen Sie bei Deployments, nicht bei Pull Requests. Das ist der mit Abstand häufigste Instrumentierungsfehler, und er lässt die Lead Time weit besser aussehen, als sie ist.

# Change Lead Time aus GitHub-Deployment-Ereignissen.
# Entscheidend: ab dem ERSTEN Commit der Änderung messen, nicht ab dem PR-Merge.
import statistics
from datetime import datetime, timezone

def lead_time_seconds(deployment_finished_at, commit_authored_at):
    return (deployment_finished_at - commit_authored_at).total_seconds()

def summarise(samples):
    """Median berichten. Lieferzeiten haben lange Ausläufer, die ein Mittelwert verdeckt."""
    if not samples:
        return None
    return {
        "p50": statistics.median(samples),
        "p90": statistics.quantiles(samples, n=10)[8] if len(samples) > 1 else samples[0],
        "n": len(samples),
    }

Warum der erste Commit und nicht der Merge? Weil die Review-Warteschlange Teil Ihrer Lead Time ist. Ein Team mit einer Zwei-Stunden-Pipeline und einem Vier-Tage-Review-Rückstau hat keine Lead Time von zwei Stunden — und ab dem Merge zu messen ist genau der Weg, auf dem dieser Rückstau für alle oberhalb des Teams unsichtbar bleibt.

Für die übrigen Metriken übersetzen sich die Definitionen in einfache Verhältnisse über ein Zeitfenster:

deployment_frequenz    = erfolgreiche_produktions_deployments / zeitfenster
change_fail_rate       = deployments_mit_sofortigem_eingriff / alle_deployments
deployment_rework_rate = ungeplante_deployments_nach_vorfall / alle_deployments

Die Eingabe, die Ihr Git-Host nicht liefern kann, ist die Information, welche Deployments sofortiges Eingreifen erforderten und welche ungeplante Vorfallsarbeit waren. Sie muss von dort kommen, wo Ihr Team die Realität ohnehin festhält — aus dem Incident-Tracker, einem Rollback-Label, einer Deployment-Annotation. Ein pragmatischer Anfang ist ein einziges Pflichtfeld an jedem Produktions-Deployment: planned, hotfix oder rollback. Drei Werte, beim Deployment ausgefüllt, genügen für beide Instabilitätsmetriken.

DORA sagt ausdrücklich, dass Teams hier überinvestieren. Integrationen über alle Systeme hinweg zu bauen, um präzise Zahlen zu bekommen, “might not be worth the initial investment” — mit Gesprächen zu beginnen oder mit dem DORA Quick Check führt oft schneller zu Verbesserung als eine perfekte Telemetrie-Pipeline.

Wer die schnellstmögliche Bestätigung will, dass die fünfte Metrik real und keine reine Dokumentationsänderung ist: DORA hat den Quick Check im April 2026 aktualisiert, sodass er die Deployment Rework Rate und neue Branchen-Benchmarks enthält. Das Werkzeug fragt sie inzwischen ab.

Wo diese Zahlen kaputtgehen

Jede DORA-Metrik hat eine triviale Gaming-Strategie. Das ist kein Mangel der Metriken; das passiert jedem Maß, das zum Ziel wird. DORA führt “Metriken zum Ziel machen” als ersten häufigen Fallstrick auf und nennt Goodharts Gesetz beim Namen.

Beachten Sie das Muster: Keine dieser Maßnahmen ändert das System, alle ändern die Erfassung. Das ist das verräterische Zeichen. Wenn sich eine Metrik verbessert und niemand eine geänderte Praxis benennen kann, hat sich die Erfassung geändert.

Die übrigen Fallstricke, die DORA benennt, lohnen sich zu kennen, weil sie in fast jeder Einführung auftauchen:

• Eine Metrik, die alle beherrscht. Komplexe Systeme brauchen mehrere Maße, die in Spannung zueinander stehen. Eine einzelne Zahl wird immer auf Kosten von etwas Ungemessenem optimiert.
• Ungleiche Vergleiche. Diese Metriken gelten für eine Anwendung oder einen Service. Eine Mobile-App mit einem Mainframe-System zu vergleichen oder Zahlen über eine ganze Organisation zu mischen, ergibt etwas, das wie eine Rangliste aussieht und nichts bedeutet.
• Getrennte Verantwortung. Wenn nur Ops für Stabilität und nur Dev für Durchsatz zuständig ist, haben Sie eine Maschine zum Fingerzeigen gebaut. Die fünf sind als gemeinsame Verantwortung gedacht.
• Wettbewerb. Ziel ist die Verbesserung gegenüber der eigenen Vergangenheit, nicht der Sieg über ein anderes Team.
• Die Branche als Schutzschild. “Wir sind reguliert, deshalb können wir nicht häufiger deployen” ist meist eine Aussage über einen Prozess, den niemand überprüft hat, nicht über die Regulierung.

Die schärfste Version dieses Problems ist der Einsatz von DORA-Metriken auf Einzelpersonen. Die Metriken sind als Prädiktoren auf Teamebene für organisationale Performance und Wohlbefinden validiert. Auf eine Person angewendet, messen sie deren Position in einer Warteschlange.

Die Ausgabe 2026 desselben Fehlers: Tokenmaxxing

Das neueste Beispiel ist gar keine DORA-Metrik — und genau das macht es lehrreich.

Im Juni 2026 veröffentlichte DORA zu einem Trend, den es Tokenmaxxing nennt: Organisationen erfassen und belohnen den reinen Verbrauch von KI-Tokens über interne Ranglisten, um die Einführung zu beschleunigen. DORAs Einschätzung ist abgewogen — diese Gamification kann KI-skeptische Entwickelnde tatsächlich zum Ausprobieren bewegen — aber das Fazit ist deutlich: Token-Verbrauch als Leistungsindikator zu behandeln, ist eine gefährliche Falle.

Es ist derselbe Fehler wie die Deployment-Frequenz im Mitarbeitergespräch, nur eine Abstraktionsebene höher. Token-Verbrauch misst Aktivität. Er lässt sich trivial maximieren, indem man mehr generiert, weniger prüft und größere Kontexte einfügt. Wer in seiner Organisation gelernt hat, blanke Commit-Zählungen nicht zu belohnen, weiß bereits, warum das hier schlecht endet.

Was KI verändert hat

DORA benannte seinen Jahresreport 2025 von Accelerate State of DevOps in State of AI-assisted Software Development um, und die Kernaussage dieser Forschung ist ein nützliches Korrektiv — sowohl gegen den Hype als auch gegen die Gegenreaktion.

KI wird als Verstärker beschrieben: Sie vergrößert die vorhandenen Stärken und Schwächen einer Organisation. Konkret fand DORA, dass KI den Durchsatz verbessert, oft aber auf Kosten der Stabilität, wenn das Fundament nicht solide ist. Der Report formuliert es so, dass die größten Erträge einer KI-Investition “not from the tools themselves, but from a strategic focus on the underlying organizational system” kommen.

Liest man das gegen das Fünf-Metriken-Modell, wirkt dessen Aufbau plötzlich vorausschauend. Wenn KI den Durchsatz hebt, während schwache Fundamente diese Geschwindigkeit in Defekte verwandeln, dann sind genau die beiden Instabilitätsverhältnisse die Metriken, die den Schaden auffangen — und eine davon, die Deployment Rework Rate, existierte vor zwei Jahren noch nicht auf Ihrem Dashboard. Ein Team, das mit KI schneller liefert und nur vier Metriken verfolgt, hat genau die Hälfte des Bildes instrumentiert, die garantiert gut aussieht.

DORAs begleitendes AI Capabilities Model von Ende 2025 benennt sieben Fähigkeiten, die den Nutzen von KI verstärken, darunter starke Versionsverwaltungspraktiken, Arbeit in kleinen Losgrößen, eine hochwertige interne Plattform, KI-zugängliche interne Daten sowie eine klare und kommunizierte KI-Haltung. Drei davon sind gewöhnliche Delivery-Hygiene, die KI um ein Jahrzehnt vorausgeht. Genau das ist der Punkt.

DORAs Folgearbeiten aus 2026 verschärfen die Warnung. Die Analyse zu den KI-Spannungen vom März 2026 beschreibt die versteckten Kosten, die mit schnellerer Codegenerierung einhergehen: Prüfaufwand, Kompetenzverlust und Integrationsreibung. Der aktuelle Report ROI of AI-assisted Software Development ist um dieselbe Realität herum gebaut und gibt Führungskräften einen Rahmen für den anfänglichen “productivity dip” einer Einführung. Nichts davon taucht im Durchsatz auf. Alles davon taucht in der Nacharbeit auf.

Eine praktische Checkliste

Wenn Sie Ihr DORA-Setup modernisieren wollen, grob nach Wirkung sortiert:

1. Zählen Sie Ihre Kacheln. Sind es vier, fehlt die Deployment Rework Rate.
2. Prüfen Sie, was Ihre Recovery-Metrik speist. Enthält sie Vorfälle, die nicht von einem Deployment stammen, ist sie nicht die Failed Deployment Recovery Time.
3. Verlegen Sie den Start der Lead Time auf den ersten Commit. Beginnt sie beim Merge, verstecken Sie Ihre Review-Warteschlange.
4. Ergänzen Sie drei Werte am Deployment-Datensatz: planned, hotfix, rollback. Beide Instabilitätsmetriken fallen daraus ab.
5. Berichten Sie Mediane — und n. Ein p50 ohne Stichprobengröße ist ein Gerücht.
6. Beschränken Sie sich auf einen Service. Über die Organisation gemischte Zahlen sind für Folien, nicht für Entscheidungen.
7. Nehmen Sie sie aus Mitarbeitergesprächen heraus. Hängen sie an individuellen Ergebnissen, ist alles Obige vergeudet.
8. Koppeln Sie jede Metrik an ein Gespräch. DORAs eigene Empfehlung ist, dass die Verbesserung aus der Diskussion über Engpässe kommt, nicht aus dem Dashboard.

Was bleibt

Streicht man die Versionsänderungen, steht DORAs zentrale Erkenntnis von 2015 unverändert — und sie ist weiterhin der Grund, warum diese Metriken zählen: Geschwindigkeit und Stabilität sind kein Zielkonflikt. Teams, die gut sind, sind es über alle fünf hinweg. Teams, die schlecht sind, sind es über alle fünf hinweg. Die Metriken korrelieren.

Dave Farleys Formulierung, die DORA im eigenen Guide zitiert, ist die, die man sich merken sollte: “the real trade-off, over long periods of time, is between better software faster and worse software slower.”

Die fünf Metriken sind ein Kompass dafür, mehr nicht. Sie zeigen Ihnen, wo Ihr Liefersystem eingeschränkt ist. Sie sagen Ihnen nicht, wen Sie befördern sollen, welches Team das beste ist oder ob sich Ihre KI-Einführung gelohnt hat — und jeder Fehlermodus in diesem Artikel entsteht daraus, ihnen eine Frage zu stellen, für die sie nie gebaut wurden.

Weiterlesen: Wenn Sie das Liefersystem bauen, das diese Metriken messen, beginnen Sie mit Platform Engineering auf Kubernetes und GitOps mit Argo CD. Für die Pipeline selbst siehe das Hardening-Playbook für sichere GitLab-CI/CD-Pipelines.

Quellen: Alle Fakten in diesem Artikel stammen aus DORAs eigenen Publikationen — dem Guide zu den Software-Delivery-Performance-Metriken, der Historie der DORA-Metriken, dem Jahresrückblick 2025 und der Übersicht zum Report 2025.