Hotfix

Freitagabend, 18 Uhr: Eine geschäftskritische Anwendung meldet Fehler. Nutzer können sich nicht mehr einloggen. Ein reguläres Update mit vollständigem Testlauf würde Tage dauern — die Anwendung kann aber keine Tage warten. Was jetzt gebraucht wird, ist ein Hotfix: eine gezielte, schnelle Korrektur, die das akute Problem behebt, ohne den Rest der Software anzufassen. Dieser Artikel erklärt, was genau ein Hotfix ist, wie er sich von verwandten Begriffen unterscheidet und wie der Prozess in der Praxis aussieht.

Zwei Programmierer sitzen mit ernsthaften Minen vor einem großen Bildschirmen und arbeiten an einem Hotifx.

1. Was ist ein Hotfix?
2. Hotfix, Patch, Bugfix, Coldfix — die Unterschiede
3. Der Hotfix-Prozess in der Praxis
4. Hotfixes und Wartungsverträge
5. Weiterführende Informationen

Was ist ein Hotfix?

Ein Hotfix ist eine dringende Softwarekorrektur, die außerhalb des regulären Release-Zyklus erstellt und eingespielt wird. Der Name setzt sich aus „hot” (im laufenden Betrieb, unter Druck) und „fix” (Fehlerbehebung) zusammen. Ein Hotfix wird dann eingesetzt, wenn ein Fehler in der Produktion so gravierend ist, dass er nicht bis zum nächsten geplanten Update warten kann.

Typische Anlässe für einen Hotfix:

Eine Sicherheitslücke wird aktiv ausgenutzt
Eine Kernfunktion der Anwendung ist ausgefallen (Login, Bezahlvorgang, Datenbankzugriff)
Ein Datenverlust droht oder ist bereits eingetreten
Eine regulatorisch relevante Funktion arbeitet fehlerhaft

Der entscheidende Unterschied zu einem normalen Update: Ein Hotfix durchläuft einen verkürzten Testprozess. Die Dringlichkeit der Fehlerbehebung wiegt schwerer als die vollständige Absicherung durch umfangreiche Regressionstests. Das macht Hotfixes zugleich notwendig und riskant.

Hotfix, Patch, Bugfix, Coldfix — die Unterschiede

Die Begriffe werden häufig durcheinander verwendet. Eine klare Abgrenzung:

Patch ist der Oberbegriff für jedes Softwareupdate, das gezielt ein Problem behebt — sei es eine Sicherheitslücke, ein Fehler oder eine Kompatibilitätsfrage. Ein Patch wird im Rahmen des regulären Patch-Management-Prozesses geplant, getestet und ausgerollt. Zeitdruck besteht, ist aber beherrschbar.

Bugfix bezeichnet die Behebung eines spezifischen Fehlers im Code. Ein Bugfix kann Teil eines regulären Patches sein oder als eigenständiges Update veröffentlicht werden. Nicht jeder Bugfix ist dringend.

Hotfix ist ein Bugfix oder Sicherheitspatch, der unter Zeitdruck erstellt und eingespielt wird — typischerweise innerhalb von Stunden statt Tagen oder Wochen. Der verkürzte Prozess ist das definierende Merkmal.

Coldfix ist das Gegenteil: Eine Korrektur, die erst beim nächsten regulären Neustart oder Wartungsfenster angewendet wird. Coldfixes betreffen Fehler, die keinen sofortigen Eingriff erfordern, aber bei der nächsten Gelegenheit behoben werden sollten.

Der Hotfix-Prozess in der Praxis

1. Erkennung und Bewertung

Ein kritischer Fehler wird gemeldet — durch das Monitoring, einen Anwender oder ein automatisches Alerting-System. Der erste Schritt: Ist das Problem wirklich ein Hotfix-Kandidat? Oder lässt es sich mit einem Workaround überbrücken, bis der reguläre Patch-Zyklus greift? Diese Bewertung sollte nicht von einer einzelnen Person getroffen werden. In vielen Organisationen gibt es dafür einen kurzen Abstimmungsprozess zwischen Entwicklung, Betrieb und dem fachlich Verantwortlichen.

2. Entwicklung

Der Hotfix wird entwickelt — so minimal wie möglich. Das Ziel ist nicht, den Code zu verbessern oder ein Redesign zu starten, sondern genau das akute Problem zu beheben. Je kleiner die Änderung, desto geringer das Risiko unbeabsichtigter Nebenwirkungen. In der Versionsverwaltung wird ein Hotfix typischerweise auf einem eigenen Branch erstellt (Hotfix-Branch), der direkt vom Production-Stand abzweigt.

3. Test (verkürzt)

Auch ein Hotfix muss getestet werden — aber der Umfang ist reduziert. Statt eines vollständigen Regressionstests konzentriert sich das Testing auf die direkt betroffene Funktion und ihre unmittelbaren Abhängigkeiten. Automatisierte Tests beschleunigen diese Phase erheblich. Anwendungen mit guter Testabdeckung können einen Hotfix in Minuten statt Stunden validieren.

4. Deployment

Der Hotfix wird auf der Produktionsumgebung eingespielt. Je nach Infrastruktur kann das ein manuelles Deployment sein oder ein automatisierter Prozess über eine CI/CD-Pipeline. Wichtig: Der Zeitpunkt des Deployments und die durchgeführten Änderungen werden dokumentiert — für die Nachvollziehbarkeit und für das spätere Post-Mortem.

5. Nachbereitung

Nach dem Deployment wird der Hotfix in den regulären Entwicklungszweig zurückgeführt (Merge), damit die Korrektur auch in zukünftigen Releases enthalten ist. Außerdem findet in der Regel ein kurzes Post-Mortem statt: Was hat den Fehler verursacht? Warum wurde er nicht durch Tests erkannt? Was kann verbessert werden, damit ein ähnliches Problem in Zukunft im regulären Prozess abgefangen wird?

Hotfixes und Wartungsverträge

Für Unternehmen, die Individualsoftware betreiben, sind garantierte Hotfix-Zeiten ein zentraler Bestandteil des Wartungsvertrags. Das SLA definiert, wie schnell der Dienstleister bei einem kritischen Fehler reagiert und wie schnell ein Hotfix bereitgestellt wird.

Typische SLA-Parameter für Hotfixes:

Reaktionszeit bei kritischen Fehlern: 1-4 Stunden
Hotfix-Bereitstellung: 4-24 Stunden (abhängig von der Komplexität)
Bereitschaft: Werktags oder 24/7 (je nach Vertrag und Kritikalität)

Ohne Wartungsvertrag wird ein Hotfix zum Ad-hoc-Projekt: Der Dienstleister muss sich erst wieder in den Code einarbeiten, Zugänge beschaffen und die Priorität des Einsatzes gegen andere Aufträge abwägen. Das kostet nicht nur mehr, sondern dauert auch deutlich länger — im schlimmsten Fall Tage statt Stunden.