Zabbix LTS does not mean five years of bug fixes — and 6.0 proves it

Every lifecycle table lists Zabbix 6.0 LTS until 28/02/2027. Full support for that line ended on 28/02/2025. Between those two dates lie two years in which Zabbix ships critical fixes for 6.0 and nothing else. The five years that “LTS” promises are three years of maintenance plus two years of afterlife. Read only the second column and you plan your migration two years too late.

Five years is three plus two

Zabbix publishes the split itself. An LTS line appears roughly every 18 months and gets three years of full support — feature updates and security fixes — followed by two years of limited support, described as critical fixes only. Together, the advertised five years.

Standard releases get the same two-phase treatment in miniature: six months of full support, then a limited phase that Zabbix describes as a minimum of six months, running until the next standard release — twelve months on paper. Two of them sit between each pair of LTS lines. That is the whole policy, and it is the reason the question “is 6.0 still supported?” has two correct and opposite answers.

Both date columns, all nine dated cycles

Six of the nine cycles are gone entirely. As of 19/08/2026 two are in full support: 7.0 LTS and 7.4. 6.0 LTS has been in the limited phase for just under eighteen months — and that is precisely the state most tables compress into “supported until 2027”.

The table shows something else. Those twelve months hold in neither direction. 6.2 was finished after not quite eight months and 5.4 after ten and a half, both short of the minimum the policy states; 6.4 ran for close to twenty-two months because 7.0 was slow to arrive. If you put a standard line into production, your planning horizon is not a year — it is the next release.

Why 7.4 is not a production decision

7.4 is a standard release. The aggregated cycle data patchletter mirrors gives 30/06/2025 as its release date, Zabbix’s own table 1 July 2025. Its end is 30/09/2026 by that cycle data, or Q4 2026 by Zabbix’s table. On 19/08/2026 both readings mean the same thing: weeks, not years.

Its successor is already scheduled. Zabbix lists 8.0 LTS under planned releases for Q3 2026, with full support to Q3 2029 and limited support to Q3 2031. In the cycle data patchletter tracks, 8.0 had not appeared as of 19/08/2026; the newest recorded version was 7.4.13, dated 29/07/2026. Read that schedule with some care: Zabbix states 1.5 years between LTS lines, while 6.0 and 7.0 were a good 27 months apart.

So the practical rule is short. For anything that has to survive a budget cycle, take 7.0 LTS — full support to 30/06/2027, limited support to 30/06/2029. Running 7.4 because you need something in it is a legitimate choice, but it is a choice with a date attached, and the date is the arrival of 8.0.

What your own instance says about its state

Zabbix grades itself. Under Reports → System information the frontend shows a status for the server and frontend version: up to date, new update available, or outdated— and “outdated” means the full support period has expired, not that the version is dead. That single label is this whole article in one word.

On the command line, every component answers -V for its version: zabbix_server -V, zabbix_agentd -V, zabbix_agent2 -V. For an instance you did not build yourself, the API answers without a login at all — apiinfo.version is documented as available to unauthenticated users only and has to be called without an auth parameter, and since Zabbix 2.0.4 the API version equals the product version:

curl -s -H 'Content-Type: application/json-rpc' \
  -d '{"jsonrpc":"2.0","method":"apiinfo.version","params":[],"id":1}' \
  https://zabbix.example.org/api_jsonrpc.php

The path depends on the installation; on package installs the frontend usually sits under /zabbix/. Note what the answer gives you: the full point version, which is the only number that tells you whether the critical fixes of the last two years are actually installed.

Moving off 6.0 is a project, not a maintenance window

The upgrade itself is friendlier than its reputation. Zabbix supports a direct upgrade to 7.4 from 7.2, 7.0, 6.4, 6.2, 6.0 and every line back to 2.0 — no chain of intermediate versions. The database schema is migrated automatically on first start, and the documentation warns plainly that this can take a long time depending on database size. Order matters: stop, upgrade and start the server first, then the proxies one after another.

The part that catches people is the proxy rule. Only proxies of the same major version are fully compatible with the server. One line older counts as outdated: such a proxy keeps collecting data and running scripts, but no longer receives configuration updates. Older than the previous LTS, or newer than the server, is unsupported outright. Agents are far more relaxed — agent from 1.4 and agent 2 from 4.4 work with a 7.4 server, as long as neither is newer than the server.

And the requirement that turns a Zabbix upgrade into an OS project: 7.0 needs PHP 8.0.0 or newer, while 6.0 still runs from PHP 7.2.5 (7.3 from 6.0.45 onwards). On an older distribution release you are not migrating Zabbix, you are migrating the box underneath it — which is exactly why three years of notice is a plan and three months is an incident.

The line decides how long — the point release decides what is fixed

Choosing LTS only buys you the length of the line. The fixes themselves arrive in the point releases, and in the limited phase that is doubly true: everything still shipped for 6.0 has already been classified as critical, which is a poor argument for skipping it. As of 19/08/2026 patchletter recorded 6.0.48 for the 6.0 line and 7.0.29 for 7.0.

Keeping track of that is a list, not a judgement call. The Zabbix product page shows the newest recorded version and the support cycles side by side, and you can have an email when a new one appears — the same mechanism that puts every 6.0.x in front of you while the line still runs. The end-of-life overview sorts everything tracked by remaining runway. Free, no account, one-click unsubscribe.

The honest limitation

“Critical fixes only” is a promise without a published threshold. Zabbix names security fixes explicitly for the full support phase; for the limited phase the wording is critical fixes, and who decides what counts as critical is the vendor. For deprecated versions the policy goes further still: critical vulnerability patches “may be addressed case-by-case”. That is a reasonable position for a vendor and a poor foundation for a five-year plan.

The dates are not perfectly aligned either. Zabbix gives quarters for anything in the future; the aggregated cycle data turns them into days. For 7.4 that is Q4 2026 against 30/09/2026 — for a change advisory board, the vendor table is the one that counts. And Zabbix keeps deprecated versions downloadable for twelve months after end of support; that is availability, not maintenance.

One thing patchletter deliberately does not do: it reports new releases, not support endings. The cycles are there to read, but nothing rings on the day.

Split into full and limited support, the planned dates for 8.0 LTS and the retention rule: Zabbix life cycle and release policy, retrieved 19/08/2026. Compatibility, upgrade paths, command line options, apiinfo.versionand the system requirements: Zabbix documentation, same date. Release dates, end-of-support dates and recorded versions from our own dataset as of 19/08/2026; the “full support until” column comes from the same aggregated cycle data at endoflife.date. For any date with consequences, Zabbix’s own table is authoritative.