The same page, the same table and the same row. On 12 August it said Q3 2026. On 4 October it said Q4 2026. Between one snapshot and the next, Zabbix's life cycle calendar moved four cells a full quarter, with no note and no announcement, and nothing changing on your server. If back in August you wrote down somewhere when you had to upgrade your monitoring, what you wrote down is no longer true.
The date, which is what you came for
November 2026. That is what Zabbix's roadmap page says today for 8.0 LTS, and the life cycle table rounds it to Q4 2026. No day has been published. 8.0.0rc2 shipped on 21 October, twenty days after rc1, and the 8.0 documentation is still labelled "development version, it may be incomplete" while 7.4 appears as "current". From today to 31 December there are 66 days.
And the other half belongs in the same sentence: November is the fourth published plan. On that same roadmap page, the date for 8.0 LTS was Q2 2026 in the 20 February snapshot, Q3 2026 in the 5 June one, September 2026 on 12 August, and November from some point before 15 October. Three slips in eight months. Being late on a major release is normal; what is rather less normal is hanging a maintenance window off it as though it were firm.
The four cells that moved
The comparison is literal and you can repeat it: two snapshots of zabbix.com/life_cycle_and_release_policy in the Internet Archive, one from 12 August 2026 and one from 4 October. In between Zabbix published release notes, of course, several of them; what none of them carries, nor the project blog, is a line saying the calendar has moved. The table changed and that was that.
The first three rows are the same news told three times: 8.0 is a quarter late against the previous revision of this page (and half a year against the first date the roadmap published), and it drags its own 2029 and 2031 expiry dates along with it. The fourth one is yours. The end of support for 7.4 — a version already installed and running in production — moved because the date of another version that does not yet exist moved. You touched nothing and your date changed.
And that Q1 2027 is not firm either, by the same mechanism. The policy says limited support for a standard branch lasts "Minimum 6 months (until next Standard Release)", and the next standard release is 8.2, which that same table places at Q1 2027. That is where 7.4's Q1 2027 comes from: it is copied from the row below. And the row below is already contradicted by the vendor on its other page, because the roadmap gives 8.2 as September 2027. Two Zabbix pages, two different dates for the version your 7.4's last day depends on.
We will make the point with the cheapest evidence to hand, which is our own. In July we wrote on this same blog that 7.4's limited support ran "until the fourth quarter of 2026" and that the life cycle page put 8.0 at "Q3 2026". Both sentences were correct the day they were published and neither is correct today. We did not copy them wrong: we copied a table correctly and the table moved afterwards. That is precisely what will happen to whatever you write down this afternoon.
"until 8.0 LTS" is not a date
In the 7.4 row, the end-of-full-support column carries neither a day nor a quarter. It carries this, verbatim: until 8.0 LTS. It is a dependency written into the cell where you expected a date. The day Zabbix ships 8.0 — whichever day in November, or December, or later — 7.4 stops having full support. You do not decide that day, you do not know it and you cannot put it in a calendar.
And the same page, a few paragraphs further up, says something else about that same version. The release policy states that a standard release carries "Full Support: 6 months". 7.4 shipped on 1 July 2025. That is nearly sixteen months ago. Both statements are true and both sit in the same document, but they do not say the same thing: one promises a duration, which on paper expired almost ten months ago, and the other a dependency on somebody else's date. The one that governs in practice is the second, and for an uncomfortable reason: your extension exists because somebody is running late. The day they stop running late, it ends.
The newer version runs out of support before the older one
The numbers from the table itself, subtracted:
Whoever moved to 7.4 in July 2025 because it was newer bought themselves, compared with whoever stayed on 7.0 LTS, roughly seven months less full support and two years and three months less limited support. The older version holds until June 2029; the more modern one has nothing left in the first quarter of 2027. It is the difference between an LTS branch and a standard one, written into the policy and in plain view. If features are exactly your question, we went through them at the time: what actually changes in Zabbix 8.0.
On what each window contains, the page is explicit for LTS branches: full support is "feature updates + security fixes" and limited support is "critical fixes only". For standard releases it gives the durations but does not describe the content. Under either reading, the end of 7.4's window is the same: Q1 2027, and after that, nothing.
Twelve months in pre-release, and three branches patched the same day
The branch opened with alpha1 on 30 October 2025 and reached rc2 on 21 October 2026: eleven months and twenty-two days, with one milestone per quarter — we went through the alphas and betas here at the time — and twenty days between the two candidates. That is a healthy cadence.
On 20 October 2026, 7.4.16, 7.0.32 and 6.0.49 all shipped on the same day. Three live branches receiving fixes that week, and the oldest of them is from February 2022: 6.0 LTS keeps limited support until 28 February 2027, barely a month before 7.4's runs out — and 7.4 shipped three and a half years later. Nothing is on fire today; there is a calendar decision, and calendar decisions get made badly in a hurry.
If you installed it from your distribution's repository, yours is not an upgrade
"Do not perform a direct upgrade, as this may result in a broken installation." That is the sentence 8.0's package-upgrade documentation uses to close its warning about the Zabbix packages your distribution ships. It says they "are not supported by Zabbix and may be outdated or missing the latest features and bug fixes", singles out Debian-based ones, and specifies that if you are coming from those — or had them installed at some point — the procedure is to uninstall the old packages, find and remove any leftover files from the previous installation, and install the official ones.
Installing Zabbix with an apt install from the Debian or Ubuntu repository was, for years, the most reasonable thing in the world: it was there, it updated along with the rest of the system and it worked. That convenience gets charged now, and not in extra hours: the plan stops being called "an upgrade" and becomes "a reinstall", with its own window and its own conversation with whoever has to approve it.
In case it helps you get your bearings before making any plan, these two commands answer where what you have came from:
# exact server version
zabbix_server -V
# which repository the package came from (Debian/Ubuntu)
apt policy zabbix-server-mysql
# the same on RHEL and derivatives
dnf list installed 'zabbix*'The window in which you see nothing
The official procedure starts by stopping the server "to make sure that no new data is inserted into database" and the second step is backing up the database. About what comes next, the documentation says this: "Depending on the database size, the database upgrade to version 8.0 may take a long time". The migration lasts as long as your history is long, and the only figure that tells you how long is how long your last test restore took.
And there is the problem no other upgrade has. Monitoring is the piece that tells you everything else has broken. While you are upgrading it, it is stopped. For that stretch — however long the schema migration takes, which you do not know in advance — your entire estate runs as if nobody were watching it, because nobody is. If something falls over halfway through, you find out when somebody phones.
Here we are boring on purpose. Nobody touches the watcher without having restored the database copy somewhere else, not merely taken it — a backup you have never tested is not a backup, it is a charm — without having measured how long that restore took, which is the real duration of your blind window, and without something watching from outside in the meantime. We keep SmokePing alongside Zabbix, and it serves for this too: when one is stopped, the other keeps measuring. If noise is your problem before the calendar is, that is what monitoring that actually warns you is about. This is the part we cover in 24/7 IT support: somebody awake, watching something that is not the system currently switched off.
When NOT to jump to 8.0
Not on day one. rc2 is five days old. A .0 of any platform spends its first weeks discovering what the tests did not surface, and your monitoring is not where you want to discover it alongside them. We do not put an x.0 into production in the first weeks unless there is a specific reason, and "it is the new one" is not a specific reason.
- If you are on 7.0 LTS and nothing in 8.0's list moves your needle: you have full support until 30 June 2027. There is no hurry; do not manufacture one. Going now buys you features you may not need and a schema migration you definitely do not.
- If you are on 7.4: here you do not have the luxury of waiting long. Your full-support window closes when 8.0 ships and the limited one ends in Q1 2027. The plan gets made now, even if the execution happens in January.
- If your installation came from the distribution repository, you already know yours is a reinstall. It needs its own window and its own rehearsal, and it does not fit in the same night as everything else.
The five lines we ask for before touching any monitoring
This is what we need to know about a monitoring platform before proposing anything. None of these entries is clever; all of them are the difference between finding out in August and finding out in January.
- Exact version and where the package came from. Not "Zabbix 7", but 7.4.16 and official repository or distribution one. That is the difference between an upgrade and a reinstall.
- Whether its row in the vendor calendar is a date or a dependency. If it says "until X ships", it is not a date: it is a risk owned by somebody else, and it gets written down as one.
- History size and how long the last test restore took. That second figure is the real length of the window in which you see nothing. If nobody has measured it, it does not exist.
- What watches the monitoring while it is stopped, and who watches that. Both halves: the probe and the person. A probe nobody looks at is decoration.
- The date somebody rereads the vendor's life cycle page. Quarterly, with a named person attached to it.
Where this fits into what we do
We run other people's monitoring with Zabbix and SmokePing, and the least glamorous part of the job is exactly this: knowing which version runs where, where the package came from and what day it stops receiving patches. That is IT maintenance in the literal sense of the words, and when you also have to prove to somebody that your systems receive security fixes, it is called compliance and continuity: a system out of support is a finding in any audit, and the date it becomes one is not set by your calendar. If you want us to look with you at which version you have and what window you really have left, let us talk.
Sources. Everything here can be checked at source. The calendar: Zabbix Life Cycle & Release Policy, consulted on 26 October 2026, source of the rows for 8.0 LTS (Q4 2026 / Q4 2029 / Q4 2031), 7.4 (1 July 2025, until 8.0 LTS, Q1 2027) and 7.0 LTS (4 June 2024, 30 June 2027, 30 June 2029), plus the policy definitions: standard releases every 6 months with 12 of support (Full Support: 6 months), LTS every 1.5 years with 5 of support (Full Support: 3 years — feature updates + security fixes; Limited Support: 2 years — critical fixes only). The four cells moving: snapshots of that same page in the Internet Archive from 12 August 2026 (8.0 LTS at Q3 2026 / Q3 2029 / Q3 2031 and 7.4 with limited support to Q4 2026) and from 4 October 2026 (already carrying today's values). The 28 June 2026 snapshot matches the August one. The November date and its three predecessors: the official roadmap, which today gives "November 2026" for 8.0 LTS and then September 2027 for 8.2, March 2028 for 8.4 and September 2028 for 9.0 LTS. The earlier dates come from snapshots of that same page in the Internet Archive: "Q2 2026" on 20 February 2026, "Q3 2026" on 5 June and "September 2026" on 12 August; by 15 October it already said November. The 8.2 discrepancy: the life cycle table places it at Q1 2027 (same cell in the June, August and October snapshots) while the roadmap gives September 2027; 7.4's Q1 2027 hangs off that 8.2 cell via "Minimum 6 months (until next Standard Release)". Our own July error — "until the fourth quarter of 2026" and "Q3 2026" — is in the post linked above, published on 30 July 2026, and is deliberately left unrewritten. Versions and dates: release notes — 8.0.0alpha1 on 30 October 2025, alpha2 on 19 February 2026, beta1 on 22 May, beta2 on 9 July, rc1 on 1 October and rc2 on 21 October; 7.4.16, 7.0.32 and 6.0.49 on 20 October 2026; the 6.0 LTS row (8 February 2022) gives end of full support on 28 February 2025 and limited support on 28 February 2027. The upgrade: the 8.0 upgrade manual (source of the sentence about how long the database migration takes), the upgrade-from-packages page (unsupported distribution packages and "Do not perform a direct upgrade…") and the Debian/Ubuntu one, with the eight procedure steps. The "development version" labelling of the 8.0 branch against "current" for 7.4 comes from the version selector on those same pages. Ours: that we operate Zabbix and SmokePing, and the rule about never touching monitoring without a tested restore, is how we work, not a vendor recommendation. The 66 days run from 26 October to 31 December 2026, and the month comparisons between 7.0 LTS and 7.4 come from subtracting the dates in the table assuming 8.0 ships in November; if it moves again, the subtraction changes, which is precisely the article's argument. Photo: "312 Adelaide Street - 6th floor server room" by Mike Beltzner, Wikimedia Commons, CC BY-SA 2.0.
Microsoft 365
ES 
CAT 
EN