Zabbix 8.0 LTS was published on 5 November 2026, and the summary doing the rounds this week is the feature list: OpenTelemetry, ClickHouse, complex event processing, MCP server, mobile app. All of that has to be built: none of it shows up switched on the day after you upgrade. What does show up unasked are six version floors rising underneath the product, and one of them leaves the server refusing to start with no parameter available to talk it round.
We run our clients' monitoring on Zabbix and SmokePing, so we read these releases less as news and more as a maintenance window. The first sum we did this morning was taking the 8.0 minimum-version table and crossing it against what the distribution repositories on those machines actually serve. The result is in the headline.
Six floors that rise at once
The 8.0.0 upgrade notes carry a short section headed Database versions and, a few lines above it, another one for PHP. Together they are this, and the arrows in the table are theirs:
| Component | Minimum on 7.4 | Minimum on 8.0 | Supported range |
|---|---|---|---|
| MySQL / Percona | 8.0.30 | 8.4.0 | 8.4.0 – 9.7.X |
| MariaDB | 10.5.00 | 10.11.00 | 10.11.00 – 12.3.X |
| PostgreSQL | 13.0 | 15.0 | 15.0 – 18.X |
| TimescaleDB | 2.13.0 | 2.20.0 | 2.20.X – 2.29.X |
| Elasticsearch | 7.0.0 | 8.0.0 | 8.0.0 – 9.5.X |
| PHP (frontend) | 8.0.0 | 8.2.0 | 8.2.0 – 8.5.X |
The fourth column deserves a slow look, because the ranges are closed at the top too: the PostgreSQL line reads 15 through 18, and the MariaDB one stops at 12.3. Your room to manoeuvre has a ceiling as well as a floor, and that changes which version you jump to if you're moving the database anyway. There's a seventh, smaller floor that only touches anyone running the Java gateway: the Logback library goes from 1.5.16 to 1.5.25.
On two of those rows we can't claim any scoop: five of the six numbers we already published on 30 July reading the beta, back when half of 8.0 was still a slide. What wasn't there then is the sixth — Elasticsearch — and the right-hand column, and those are exactly the two that decide the order of the work.
Five have a ladder. One is a wall
Zabbix has had an escape valve for this for years. The server config file carries a parameter, AllowUnsupportedDBVersions, described in one line — "Allow server to work with unsupported database versions" — with a default of 0. Setting it to 1 is the difference between a start-up that fails and one that merely complains. It isn't free and we don't recommend it as a plan, but it exists and it occasionally buys you the night you need.
Except on one row. The upgrade notes write it leaving no gap: "Zabbix server does not start if the Elasticsearch version is older than 8.0.0; this cannot be overridden with the AllowUnsupportedDBVersions parameter". Of the six floors, five can be stepped over knowingly and at your own risk. The Elasticsearch one can't: there, upgrading Zabbix depends on having upgraded an entirely different product first, and you don't get to pick the order.
Where your distribution lands
This table isn't in any release note because it crosses two sources nobody puts together: the minimums above and what each distribution's archive serves. We checked it this morning, package by package, on packages.debian.org and packages.ubuntu.com, for the five distributions you actually run into in production today:
| Distribution | PostgreSQL | MariaDB | MySQL | PHP |
|---|---|---|---|---|
| Debian 11 bullseye | 13 ✗ | 10.5.29 ✗ | — | 7.4 ✗ |
| Debian 12 bookworm | 15 ✓ | 10.11.19 ✓ | — | 8.2 ✓ |
| Debian 13 trixie | 17 ✓ | 11.8.6 ✓ | — | 8.4 ✓ |
| Ubuntu 22.04 jammy | 14 ✗ | 10.6.22 ✗ | 8.0.46 ✗ | 8.1 ✗ |
| Ubuntu 24.04 noble | 16 ✓ | 10.11.13 ✓ | 8.0.46 ✗ | 8.3 ✓ |
What surprised us most is in the fourth row. Ubuntu 22.04 clears none of the four packages it serves, and it isn't an abandoned distribution: it has standard support until May 2027. Putting 8.0 on it means adding external repositories for the database and for PHP, and taking over maintaining them. A row further down, 24.04 fails in only one column, but it's a column that matters: it serves MySQL 8.0.46 when the floor is 8.4.0, so no Ubuntu LTS today ships a MySQL that qualifies, and anyone on that engine is changing repositories even on the newest release.
And one coincidence that says plenty: Debian 12 hits all three minimums exactly — PostgreSQL 15, MariaDB 10.11, PHP 8.2. The only archive that fits without touching anything belongs to the release that stopped being the stable one in August and now sits as oldstable on debian.org.
Zabbix, for its part, doesn't hide the consequence. Its own requirements page puts it in a sentence: "Although Zabbix can work with databases available in the operating systems, for the best experience, we recommend using databases installed from the official database developer repositories". In other words, the vendor already assumes your database won't come from your distribution. What it doesn't say is the cost: one more repository in the inventory, one more key that expires, and one more component upgrading on its own calendar.
Where they drew the line: a measurement in the repo
There's a way to see what the vendor itself considers acceptable, and it isn't in the documentation: it's in the package index. This morning we downloaded the architecture-independent Packages files from repo.zabbix.com/zabbix/8.0/stable for six distributions. On Debian 11 and Ubuntu 20.04 — both on PHP 7.4 — the repository serves exactly two packages, the Java gateway and the SQL scripts: there is no frontend. On Debian 12, Debian 13, Ubuntu 22.04 and Ubuntu 24.04 it serves five, and zabbix-frontend-php is among them.
Before reading anything into it, put the boring explanation up front: Debian 11 left the LTS team's support on 31 August 2026 and Ubuntu 20.04 left standard support in May 2025, so the likeliest reason is simply that Zabbix doesn't build a frontend for dead distributions. What doesn't change is the consequence. The line, whatever the reason, was not drawn at the published minimum: Ubuntu 22.04 ships PHP 8.1 — below the 8.2.0 that 8.0 requires — and still gets its frontend package, 2:8.0.0-1+ubuntu22.04, whose dependencies carry no version at all: php-mysql | php-pgsql, php-mbstring, php-bcmath, php-xml, php-gd, php-ldap, php-curl, fonts-dejavu | ttf-dejavu-core | ttf-japanese-gothic. Translated: apt will not stop you. The package installs against the distribution's PHP 8.1 without a single complaint, and the requirement turns up later, when the frontend meets an interpreter outside its range.
The same border shows up again in the headline feature. Using the new OpenTelemetry application monitoring needs a proxy built with APM support, and the notes say where it already comes included: Debian 12 or later, Raspberry Pi OS 12 or later, Ubuntu 24.04 or later. For every other system — RHEL 10 has its own route, with the EPEL repository, the CRB repository enabled and a separate package — "upgrade Zabbix proxy from sources with the --with-apm option". On Ubuntu 22.04, the feature of the year is a hand build.
Two things expire on 12 November
Zabbix's lifecycle table now carries exact dates where in October there were quarters: 8.0 LTS shipped on 5 November 2026, with full support to 30 November 2029 and limited support to 30 November 2031. And on the row below, 7.4 loses full support on 12 November 2026 — five days from now. Two weeks ago we wrote that this cell held no date but the string until 8.0 LTS; now it has a number.
12 November 2026 is also, by pure coincidence of other people's calendars, the end-of-life date for PostgreSQL 14: its final minor release is 14.24 and the project's versioning policy retires it that day. Which means that on the same day your 7.4 stops receiving features and fixes, the database Ubuntu 22.04 ships stops receiving patches. If you want the detail of why nothing will warn you about that expiry, we wrote it a few days ago: PostgreSQL 14 goes end of life and nothing will tell you.
And now the nuance that changes the decision, straight from the same PostgreSQL table: 15 — the floor Zabbix 8.0 asks for — reaches end of life on 11 November 2027. Jumping exactly to the minimum buys you one year. 16 runs to November 2028 and 17 to November 2029, which happens to be the month 8.0 itself loses full support. If you're going to stop the server and migrate the database anyway, choosing the minimum out of caution is the option most likely to make you repeat the window.
What breaks without saying anything
A version floor announces itself: the service doesn't start and you see it. The rest of the breaking-change list is worse, because everything keeps running and what's missing is alerts that no longer fire. The five we note down to review after every upgrade:
- 1.Retired macros in message templates. Gone are
{HOSTNAME<1-9>},{IPADDRESS<1-9>},{STATUS},{USER.ALIAS},{TRIGGER.KEY},{ACK.MESSAGE}and the rest of the{ACK.*}and{PROFILE.*}family. An alert email that no longer says which machine it refers to still arrives, right on schedule. - 2.An empty API allow list now denies. It used to be ignored and everything was permitted. To avoid breaking anything, the note says, "the upgrade adds the * wildcard (any method) to all user roles that have Allow list selected but no methods specified". Which means the compatibility measure leaves those roles with the whole API open, and reviewing it is on you.
- 3.The Microsoft Teams webhook no longer works. This isn't a future warning: the classic media type rested on Office 365 connectors, which Microsoft retired on 22 May 2026, and the notes call it no longer functional. The replacement is the Workflow webhook, and the configuration has to be migrated by hand.
- 4.TLS verification on by default in templates and webhooks. Anything speaking HTTPS now validates the endpoint certificate. It's the right call, but if you monitor a box with a self-signed certificate, the day you update that template the item goes quiet. It's governed by the new
{$HTTP.TLS.VERIFY}macro and its three values:none,peerorfull. - 5.The Ceph plugin changes mode and package. The
restfulmode is still the default — already flagged as deprecated — and the notes warn it will not work with Ceph 20 (Tentacle) or newer, because themgr/restfulmodule has been removed. Thenativemode speaks the native msgr2 protocol, runs on Linux only and from Ceph 16 onwards, and the same page warns that "the user credential set differs for each mode and they are not compatible with each other". On top of that, the plugin is now loadable and installed separately. Anyone who already moved to Tentacle and left the agent alone has flat graphs.
When we wouldn't jump yet
Not out of distrust: a freshly released LTS is good news for anyone planning three years out. But there are three situations where hurrying costs more than it saves:
- —If you're on 7.0 LTS. You have full support until 30 June 2027. 12 November isn't your date; yours is seven and a half months out, and that's enough room to do the database jump deliberately, separate from the Zabbix upgrade.
- —If the database jump lands in the same window. Upgrading Zabbix and changing engines at once turns any failure into an argument about which of the two caused it. Two windows two weeks apart explain themselves better than one long window you can't undo.
- —If what's pulling you is the feature list. APM, ClickHouse, complex event processing and the MCP server are projects with their own budget. None of them switch on when you upgrade. If your reason to jump this week is OpenTelemetry, the real work starts after the window and deserves to be budgeted whole.
Five checks before you set a date
None of them changes anything. All five fit in an afternoon, and they decide whether your upgrade is an afternoon or a project:
- 1.The exact engine version:
SELECT version();on PostgreSQL orSELECT VERSION();on MySQL and MariaDB. Write down all three numbers. - 2.Where that package came from:
apt policy postgresqlordnf list installed. If it came from the distribution archive, the table above already tells you whether you clear the floor. - 3.
php -von the frontend host, which isn't always the same machine as the database, nor the same as the Zabbix server. - 4.If you use Elasticsearch for history, its version before touching anything: it's the one floor with no escape valve, and it sets the order of the whole plan.
- 5.A search for
HOSTNAME1,IPADDRESS1,USER.ALIASandACK.across your message templates. Whatever turns up is an alert that, after the window, will say less than it used to.
Two hours of a morning, and what ends up in the notebook isn't a feature list: it's the version of four engines, the date on a repository and the name of a package installed by somebody who no longer works here. 8.0 is a good LTS and we will end up running it everywhere. The calendar, though, is set by the layer underneath.
At everyWAN we run monitoring as part of 24×7 IT support, and these windows fall under the IT maintenance of clients whose estate we look after. We don't resell anyone's licences, so when we say your jump to 8.0 can wait until January, we're not turning down a project by saying it.
Sources (verified on 2026-11-07): release date and contents — Release Notes for Zabbix 8.0.0 (5 November 2026); database and PHP minimums, the Elasticsearch quote, the dropped macros, the API allow-list wildcard, TLS verification, the Teams webhook, the Ceph plugin modes and the APM packages — What's new and upgrade notes: 8.0; supported ranges and the sentence about the database vendor's own repositories — Requirements; AllowUnsupportedDBVersions and its default — zabbix_server; lifecycle dates for 8.0, 7.4 and 7.0 — Zabbix Life Cycle and Release Policy; end-of-life dates for PostgreSQL 14 (12-11-2026, final 14.24), 15 (11-11-2027), 16 and 17 — PostgreSQL Versioning Policy; distribution archive versions — packages.debian.org and packages.ubuntu.com; Ubuntu 22.04 standard support to May 2027 and Ubuntu 20.04 to May 2025 — Ubuntu release cycle; Debian 12 oldstable status — debian.org/releases; end of Debian 11 LTS support on 2026-08-31 — wiki.debian.org/LTS. The distribution table and the per-distribution package counts are our own measurement against the public indexes of repo.zabbix.com, taken on 2026-11-07 and reproducible by downloading the Packages files. Photograph: CERN computer room, by Hugovanmeijeren, CC BY-SA 3.0 via Wikimedia Commons, cropped by us.
Is your Zabbix on Ubuntu 22.04 with nobody sure which repository the database came from?
We inventory the versions, tell you whether your jump is an afternoon or a project, and run it with the window and the rollback written down. With your numbers.
Talk to everyWAN