Zabbix LTS heißt nicht fünf Jahre Bugfixes — und Zabbix 6.0 beweist es
Jede Lifecycle-Tabelle führt Zabbix 6.0 LTS bis zum 28.02.2027. Voll gepflegt wird die Linie seit dem 28.02.2025 nicht mehr. Dazwischen liegen zwei Jahre, in denen Zabbix für 6.0 kritische Korrekturen liefert und sonst nichts. Die fünf Jahre, die „LTS“ verspricht, sind drei Jahre Pflege plus zwei Jahre Nachlauf. Wer nur die zweite Spalte liest, plant seine Migration zwei Jahre zu spät.
Fünf Jahre sind drei plus zwei
Zabbix veröffentlicht die Aufteilung selbst. Eine LTS-Linie erscheint etwa alle anderthalb Jahre und bekommt drei Jahre volle Pflege — Funktionsupdates und Sicherheitskorrekturen — und danach zwei Jahre eingeschränkte Pflege, beschrieben als ausschließlich kritische Korrekturen. Zusammen die beworbenen fünf Jahre.
Für Standardreleases gilt dieselbe Zweiteilung in klein: sechs Monate volle Pflege, danach eine eingeschränkte Phase, die Zabbix als mindestens sechs Monate bis zum nächsten Standardrelease beschreibt — auf dem Papier also zwölf Monate. Zwischen zwei LTS-Linien liegen genau zwei davon. Das ist die ganze Politik — und der Grund, warum die Frage „wird 6.0 noch unterstützt“ zwei richtige, entgegengesetzte Antworten hat.
Beide Datumsspalten, alle neun datierten Zyklen
| Linie | Erschienen | Volle Pflege bis | Support-Ende |
|---|---|---|---|
| 7.4 | 30.06.2025 | bis 8.0 LTS | 30.09.2026 |
| 7.2 | 10.12.2024 | 30.06.2025 | 31.12.2025 |
| 7.0 LTS | 04.06.2024 | 30.06.2027 | 30.06.2029 |
| 6.4 | 06.03.2023 | 30.06.2024 | 31.12.2024 |
| 6.2 | 04.07.2022 | 31.01.2023 | 28.02.2023 |
| 6.0 LTS | 08.02.2022 | 28.02.2025 | 28.02.2027 |
| 5.4 | 17.05.2021 | 28.02.2022 | 31.03.2022 |
| 5.0 LTS | 11.05.2020 | 31.05.2023 | 31.05.2025 |
| 4.0 LTS | 01.10.2018 | 31.10.2021 | 31.10.2023 |
Sechs der neun Zyklen sind vollständig durch. Am 19.08.2026 stehen zwei in voller Pflege: 7.0 LTS und 7.4. 6.0 LTS ist seit knapp anderthalb Jahren in der eingeschränkten Phase — und genau dieser Zustand wird in den meisten Tabellen zu „unterstützt bis 2027“ zusammengefasst.
Die Tabelle zeigt noch etwas: Diese zwölf Monate sind in keine Richtung verlässlich. 6.2 war nach knapp acht Monaten am Ende und 5.4 nach zehneinhalb, beide also unter dem selbst genannten Mindestmaß; 6.4 lief dafür fast 22 Monate, weil 7.0 auf sich warten ließ. Wer eine Standardlinie in Produktion nimmt, plant nicht mit einem Jahr, sondern mit dem nächsten Release.
Warum 7.4 keine Produktionsentscheidung ist
7.4 ist ein Standardrelease. Als Erscheinungsdatum führen die aggregierten Zyklusdaten, die patchletter spiegelt, den 30.06.2025, Zabbix’ eigene Tabelle den 1. Juli 2025. Das Ende liegt nach diesen Zyklusdaten am 30.09.2026, nach Zabbix’ Tabelle im vierten Quartal 2026. Am 19.08.2026 bedeuten beide Lesarten dasselbe: Wochen, keine Jahre.
Der Nachfolger steht schon im Plan. Zabbix führt 8.0 LTS unter den geplanten Releases für das dritte Quartal 2026, mit voller Pflege bis Q3 2029 und eingeschränkter bis Q3 2031. In den Zyklusdaten, die patchletter verfolgt, war 8.0 am 19.08.2026 noch nicht aufgetaucht; die neueste erfasste Version war 7.4.13 vom 29.07.2026. Diesen Plan liest man besser mit Vorbehalt: Zabbix nennt anderthalb Jahre zwischen zwei LTS-Linien, zwischen 6.0 und 7.0 lagen tatsächlich gut 27 Monate.
Die praktische Regel ist kurz. Was einen Haushaltszyklus überleben soll, läuft auf 7.0 LTS — volle Pflege bis 30.06.2027, eingeschränkte bis 30.06.2029. 7.4 zu fahren, weil man ein Merkmal daraus braucht, ist eine legitime Entscheidung; sie hat nur ein Datum angehängt, und das Datum ist das Erscheinen von 8.0.
Was die eigene Instanz über ihren Zustand sagt
Zabbix benotet sich selbst. Unter Reports → System information zeigt das Frontend für Server- und Frontend-Version einen Status an: aktuell, Update verfügbar oder outdated — und „outdated“ heißt dort, dass die volle Pflege abgelaufen ist, nicht dass die Version tot wäre. Dieses eine Wort ist der ganze Artikel.
Auf der Kommandozeile antwortet jede Komponente auf -V mit ihrer Version: zabbix_server -V, zabbix_agentd -V, zabbix_agent2 -V. Bei einer Instanz, die man nicht selbst aufgesetzt hat, antwortet die API sogar ohne Anmeldung — apiinfo.version ist laut Handbuch ausschließlich unangemeldeten Aufrufern vorbehalten und muss ohne Auth-Parameter aufgerufen werden; seit Zabbix 2.0.4 entspricht die API-Version der Produktversion:
curl -s -H 'Content-Type: application/json-rpc' \
-d '{"jsonrpc":"2.0","method":"apiinfo.version","params":[],"id":1}' \
https://zabbix.example.org/api_jsonrpc.phpDer Pfad hängt von der Installation ab; bei Paketinstallationen liegt das Frontend meist unter /zabbix/. Wichtig ist, was die Antwort liefert: die vollständige Punktversion. Sie ist die einzige Zahl, an der man sieht, ob die kritischen Korrekturen der letzten zwei Jahre tatsächlich installiert sind.
Der Umstieg von 6.0 ist ein Projekt, kein Wartungsfenster
Das Upgrade selbst ist freundlicher als sein Ruf. Zabbix unterstützt das direkte Upgrade auf 7.4 aus 7.2, 7.0, 6.4, 6.2, 6.0 und jeder Linie zurück bis 2.0 — keine Kette von Zwischenversionen. Das Datenbankschema wird beim ersten Start automatisch migriert, und das Handbuch warnt unmissverständlich, dass das je nach Datenbankgröße lange dauern kann. Die Reihenfolge zählt: erst Server anhalten, aktualisieren, starten, danach die Proxies einzeln.
Woran es in der Praxis hakt, ist die Proxy-Regel. Voll kompatibel sind nur Proxies derselben Major-Version. Eine Linie älter gilt als outdated: So ein Proxy sammelt weiter Daten und führt Skripte aus, bekommt aber keine Konfigurationsänderungen mehr. Älter als das vorherige LTS oder neuer als der Server ist gar nicht unterstützt. Bei Agenten ist Zabbix großzügig — Agent ab 1.4 und Agent 2 ab 4.4 arbeiten mit einem 7.4-Server zusammen, solange keiner von beiden neuer ist als der Server selbst.
Und die Voraussetzung, die aus dem Zabbix-Upgrade ein Betriebssystem-Projekt macht: 7.0 verlangt mindestens PHP 8.0.0, während 6.0 noch ab PHP 7.2.5 läuft (ab 6.0.45 mindestens 7.3). Auf einem älteren Distributionsstand migrierst du nicht Zabbix, sondern die Maschine darunter — und genau deshalb sind drei Jahre Vorlauf ein Plan und drei Monate ein Vorfall.
Die Linie entscheidet, wie lange — die Punktversion, was behoben ist
Die Entscheidung für LTS kauft nur die Länge der Linie. Die Korrekturen selbst kommen in den Punktversionen, und in der eingeschränkten Phase gilt das doppelt: Alles, was für 6.0 überhaupt noch erscheint, ist bereits als kritisch eingestuft — ein schlechtes Argument, es auszulassen. Am 19.08.2026 hatte patchletter für die Linie 6.0 die 6.0.48 erfasst und für 7.0 die 7.0.29.
Das im Blick zu behalten braucht kein Urteilsvermögen, nur eine Liste. Die Produktseite zu Zabbix zeigt die neueste erfasste Version und die Support-Zyklen nebeneinander, und du kannst dir eine Mail schicken lassen, sobald eine neue erscheint — derselbe Mechanismus, der dir jedes 6.0.x vorlegt, solange die Linie noch läuft. Die End-of-Life-Übersicht sortiert alles Verfolgte nach Restlaufzeit. Kostenlos, ohne Konto, Abmeldung mit einem Klick.
Die ehrliche Einschränkung
„Nur kritische Korrekturen“ ist eine Zusage ohne veröffentlichte Schwelle. Sicherheitsfixes nennt Zabbix ausdrücklich für die volle Pflege; für die eingeschränkte Phase steht dort „kritische Korrekturen“, und was kritisch ist, entscheidet der Hersteller. Für abgekündigte Versionen geht die Politik noch weiter: Patches für kritische Schwachstellen werden dann „von Fall zu Fall“ behandelt. Das ist für einen Hersteller eine vernünftige Position und für eine Fünfjahresplanung eine schlechte Grundlage.
Auch die Daten decken sich nicht überall. Zabbix nennt für alles Künftige Quartale, die aggregierten Zyklusdaten machen Tage daraus. Bei 7.4 steht Q4 2026 gegen den 30.09.2026 — für ein Änderungsgremium gilt die Herstellertabelle. Und abgekündigte Versionen bleiben bei Zabbix noch zwölf Monate nach dem Support-Ende herunterladbar; das ist Verfügbarkeit, nicht Pflege.
Was patchletter ausdrücklich nicht tut: Es meldet neue Releases, keine Support-Enden. Die Zyklen stehen da zum Nachlesen, aber am Stichtag klingelt nichts.
Aufteilung in volle und eingeschränkte Pflege, die Planzahlen zu 8.0 LTS und die Frist für abgekündigte Versionen: Zabbix Life Cycle & Release Policy, abgerufen am 19.08.2026. Kompatibilität, Upgrade-Pfade, Kommandozeilenoptionen, apiinfo.version und die Systemvoraussetzungen: Zabbix- Dokumentation, gleiches Datum. Erscheinungsdaten, Support-Enden und erfasste Versionsstände aus dem eigenen Bestand, Stand 19.08.2026; die Spalte „Volle Pflege bis“ stammt aus denselben aggregierten Zyklusdaten von endoflife.date. Maßgeblich für jedes Datum mit Konsequenz bleibt Zabbix’ eigene Tabelle.