Zabbix 8.0: what actually changes and what is still a slide

One detail sums up the real state of Zabbix 8.0 better than any press release: in the official container registry, 7.4 carries the alpine-latest and latest tags, and 8.0 carries alpine-trunk. Trunk is the development branch. As of 30 July 2026, the latest published 8.0 artefact is beta 2, dated 9 July. And it has still been going around for months as if it were installed somewhere.

We monitor customer infrastructure with Zabbix: Proxmox clusters with Ceph, our own network, services and applications, with Grafana on top for whatever has to be shown to someone who never opens the console. So 8.0 matters to us for what it will change during our on-call shift, not for the headline. That is what this post is: what it really brings, what is still a roadmap slide, and where the bill for the upgrade sits — which is not in the features, it is in the upgrade notes.

Where 8.0 actually is

The public timeline, as it stands in the official release notes:

When it lands it will be LTS: full support until Q3 2029 and limited support until Q3 2031, per the official lifecycle policy. That is three years of full support and five until limited support runs out. It is what makes this version matter more than any 7.6: whatever you install now will be with you well into the decade.

What the roadmap promises and does not show up in the notes yet

The official Zabbix roadmap puts a list under 8.0 LTS that, if this is your job, is the reason you are waiting for it:

• OpenTelemetry data collection and visualisation, log-based observability and a storage engine optimised for telemetry.
• Complex event processing engine: tag and severity changes, filtering, deduplication, pattern matching and custom JavaScript processing.
• Permissions for proxies and proxy groups, with a permission-based visibility model.
• Mobile application for iOS and Android with push notifications, and an MCP server so AI agents can query monitoring data.

Now the uncomfortable part: none of that list appears in the alpha1, alpha2, beta1 or beta2 release notes, nor on the official "What's new in Zabbix 8.0" page as of today. Not OpenTelemetry, not the complex event processing engine, not proxy permissions, not the app.

It is worth saying what that means and what it does not. It does not mean it will not arrive: there is a beta or two and a release candidate left, and big features sometimes land late in the cycle. Nor is it a dig at Zabbix, which publishes its roadmap with names and dates — not everyone does — and is right not to ship a half-baked LTS. It means one concrete, operational thing: if your observability plan for this year rests on Zabbix's OpenTelemetry, today you are resting on a roadmap, not on a binary. Those two things get planned differently.

And a note for reading the small print: what is dated as 8.2 (March 2027) includes NetFlow, automated topology discovery and centralised log management with syslog. If someone sold you that as part of 8.0, they sold you the whole roadmap at once.

What is actually there: less flashy, more useful

What is in the beta will not make a headline, and it is exactly what changes daily life for whoever operates the thing. Three real ones:

1. JSON as a native value type

Until now, a JSON response from an API was collected in a text item and stored as a string, capped at 64 KB. In 8.0 there is a real JSON data type, with a 128 MiB limit (134,217,728 bytes) and validation: JSON with unquoted keys, trailing commas or mismatched brackets is rejected instead of being stored as silent garbage. It is available on all item types and prototypes except calculated ones, on every supported database and on Elasticsearch — with the documented caveat that Elasticsearch does not accept JSON arrays: it has to be an object or a set of objects — and also in real-time export and connectors.

The honest caveat, which the documentation states and the summaries skip: a JSON item cannot be used in a trigger. To fire on a field you have to extract it with a dependent item of a non-JSON type. In other words: it changes where you store the bulk, not how you alert. Even so, for anyone collecting API output from Ceph, a hypervisor or a cloud — us — it is the difference between chopping things up by hand in preprocessing and having the whole object available.

2. ClickHouse as a history backend

You can use ClickHouse to store item value history, with supported versions from 25.8.22 to 26.4. And with it comes a configuration change that is not cosmetic: the server parameters HistoryStorageURL, HistoryStorageTypes and HistoryStorageDateIndex are replaced by HistoryProviders, and in the frontend $HISTORY becomes $HISTORY_PROVIDERS. That is not a new widget: it means history stops being "the database" and becomes a pluggable provider. If you have spent years fighting the size of the history table, that sentence tells you more than the entire UI news section.

3. c-ares: the improvement you only appreciate at three in the morning

The server, the proxy and the agent can use c-ares for all DNS requests, with query caching and resolver failover. It sounds like a footnote. It is not: anyone with thousands of hosts defined by name knows exactly what happens when the resolver coughs — an avalanche of "cannot resolve" that looks like a network outage and is not. Giving resolution its own cache and the ability to switch resolvers wipes out an entire family of false positives. Fewer false positives caused by something that is not the cause.

And there is more plumbing along the same lines: engineID caching and reuse in SNMPv3, SNMPv1 and v2 asynchronous checks processed concurrently, faster server startup thanks to bulk history fetching, and refined proxy throttling logic so the server holds up better while recovering the history cache. None of this makes a slide. All of this shows up on a loaded cluster.

The bill for the upgrade is in the upgrade notes

This is where it stops being an entertaining read and turns into work. The minimums go up, and they go up hard:

Translated into what it means on a Tuesday afternoon: if your Zabbix runs on the PostgreSQL that came with the distribution, upgrading Zabbix is first and foremost upgrading the database engine where your history lives. Two major PostgreSQL versions are not skipped with an apt; and if you are on MySQL, the 8.0 to 8.4 jump drags its own changes along. There is also an explicit warning for anyone who created the database with the utf8mb3 character set: converting it to utf8mb4 is strongly recommended.

And then there is what breaks quietly. 8.0 removes deprecated macros that have been alive in notification actions for a decade:

Look at where those macros usually live: in the text of the email or the on-call message. What breaks is not a pretty graph someone notices the next day; it is the alert. And a broken alert is not detected until you need it, which is exactly the worst moment. It is the same pattern we wrote about in alert fatigue: the problem is never the graph, it is that the alert arrives and means something.

The rest of the "this is going to hurt" list from the official notes:

• API: the massupdate method is removed from host, template, hostgroup and templategroup, along with hostinterface.replacehostinterfaces. If you have host onboarding automated against the API — and you should — review it before touching anything.
• JavaScript preprocessing: built-in object methods become read-only and modifying prototypes is forbidden. Any script copied off a forum that patched a prototype stops working.
• Agent: the % character is added to the UnsafeUserParameters list in both agents. If you have UserParameters with percent signs, review them.
• Ceph: the agent 2 Ceph plugin becomes a loadable plugin and requires additional installation steps. Anyone running Ceph is squarely affected — us, for a start.

What is a headline and does not change how you operate

Part of the release takes up a lot of room in the summaries and very little in operations: the new scatter plot widget for correlating two metrics, Y-axis inversion in graphs, customisable tables in Hosts, Latest data and Problems, marker clustering on the geomap. It is fine. It is a widget. And there are over thirty new templates — AWS, Azure, Kubernetes, Podman, Oracle Cloud, GLPI — including templates to monitor the OpenAI and Claude APIs: good old monitoring keeping an eye on this year's fashion.

Two fair exceptions, because not everything visible is smoke. Dashboard import and export does change something real: it turns panels into a file you can version and deploy like the rest of the configuration, instead of an artefact somebody assembled by hand that nobody can reproduce. And the modernised UI matters more than it looks when you have someone on call in front of it in the middle of an incident: console ergonomics are not aesthetics, they are response time. 8.0 also brings the Proxmox VE template converted to nested discovery, which fits what we wrote when Proxmox integrated Zabbix as official monitoring.

How we look at a release like this

Here is our part, and it deliberately comes without a recipe. We do not run Zabbix hand-installed on an Ubuntu box. Server, proxy and frontend are versioned containers on our own platform — Docker Swarm with Portainer and Traefik, deployed by CI/CD from GitLab — like everything else we run. This is not tech posturing: with a release like this one the difference shows up in four specific places.

• Testing the beta is not touching production. Bringing up trunk against a copy of the history and seeing what breaks — macros, preprocessing scripts, API calls — is just another environment, not an adventure on the server that watches your customers.
• The upgrade is changing an image tag, with one honest caveat worth saying out loud: the database schema does not roll back on its own. Zabbix migrates the schema when the new version starts; going back to the previous one requires restoring the database. Rolling back the container is trivial, rolling back the data has to be planned. Anyone selling you an LTS rollback as if it were free has never done one.
• Scaling proxies is replicating a service, not building another box. When every site or every customer needs its own collection point, the difference between declaring one more service and provisioning one more server is the difference between an afternoon and a week.
• And order matters. With database minimums going up two major versions, separating the data engine from the application server stops being architectural elegance and becomes the way to do one thing at a time.

One detail ties all of this together and has cost us explanations before: trunk, like latest, is not a version. It is a moving pointer. Running production against a moving pointer is exactly how your monitoring changes version one day without anyone deciding it. We covered it in full in "latest" is not a version.

What we would do with this in August

Our default recommendation will disappoint anyone expecting a migration plan: do not upgrade the day 8.0.0 ships. Wait for the first minor releases. An LTS you will be dragging along until 2031 deserves two months of other people finding the edges. In the meantime, there is useful work you can do today that does not depend on Zabbix publishing anything:

• Inventory the removed macros. Grep your actions, templates and scripts for {HOSTNAME, {IPADDRESS, {ACK., {EVENT.ACK.HISTORY}, {PROFILE., {TRIGGER.COMMENT}, {TRIGGER.KEY}, {STATUS} and {USER.ALIAS}. You can replace them today, on 7.x, without waiting for anything: the replacements already work.
• Search for massupdate in your automation. Same reasoning: it can be rewritten beforehand, calmly, instead of finding out when bulk host creation returns an error.
• Check your database version. That is the real work of the upgrade, and probably what eats the most maintenance window. Knowing today turns the conversation from "we upgrade Zabbix" into "we upgrade the database and then Zabbix".
• Locate your clock. If you are on 7.0 LTS you have full support until 30 June 2027: there is no rush, let 8.0 mature. If you are on 7.4, a standard branch, full support runs until 8.0 ships and limited support until Q4 2026: there is a clock there, and planning should start now even if execution happens in autumn.

Zabbix 8.0 will probably be a good LTS. But the version you can evaluate today is not the one the headlines describe, and the part that will really cost you time is none of the features they mention. It is your database and your macros. Start there.

Sources (verified): dates and contents of 8.0.0alpha1 (30 Oct 2025), 8.0.0beta1 (22 May 2026) and 8.0.0beta2 (9 Jul 2026) — official release notes. Release features (ClickHouse, JSON, customisable tables, scatter plot, templates, c-ares) — "What's new in Zabbix 8.0". Database and PHP minimums, removed macros, read-only JavaScript preprocessing, UnsafeUserParameters, loadable Ceph plugin and HistoryProviders — official 8.0 upgrade notes. The 128 MiB limit of the JSON type and its trigger restriction — item documentation; the Elasticsearch restriction on JSON arrays, on the Elasticsearch setup page. Removed API methods — API changes in 8.0. Supported database and PHP versions — 8.0 requirements. Roadmap contents and dates (8.0 LTS in September 2026, 8.2 in March 2027, OpenTelemetry, complex event processing engine, mobile app, proxy permissions, MCP server) — official roadmap. Lifecycle and support dates for 7.0, 7.4 and 8.0 — life cycle and release policy. Official container image tags (latest for 7.4, alpine-trunk for 8.0) — official Zabbix repository on Docker Hub. Proxy groups with load balancing and high availability have existed since 7.0, they are not new in 8.0 — what's new in 7.0. The reading of what matters and what does not, the criterion of waiting for the first minor releases and the recommended preparatory work are ours. Image: NASA control room (Johnson Space Center, April 2026), public domain.