When one Zabbix server is enough and when to add HA or proxies
A single Zabbix server is enough for a smaller or single-site estate where a restart window is tolerable, because the server, its database and its collection work all sit in one place that is simple to back up and upgrade. Zabbix high availability is the answer to a different question: what happens when the server node itself fails. In a Zabbix server high availability cluster, one node is active, the others stand by, and all nodes use the same database. Standby nodes run only the HA manager and do not collect data or listen on ports. The failover delay is configurable from 10 seconds to 15 minutes, with a default of one minute, and a node that stops cleanly is replaced within 5 seconds. Ask yourself how long your monitoring can be blind during a failover and whether that matches your alerting obligations.
HA does not replace database redundancy. The Zabbix documentation says the native solution has no specific database requirements and warns that database replication must be in sync during upgrades, so a highly available database has to be designed and tested separately, and a database failure still takes monitoring down. Proxies raise a different set of decisions. A proxy collects data on behalf of the server, stores it locally during short outages so no data is lost, and suits sites with unreliable links or thousands of devices, but it must use its own separate database. Check that each proxy has a database to back up and patch, and confirm with your own environment how many proxies and database instances your operations team can run.
Proxy groups address a third need: offloading collection and surviving a proxy loss. From Zabbix 7.0 onward, proxy groups redistribute monitored hosts across proxies when one goes offline, which matters when a remote site depends on a single collector. Active proxies connect to the server and request their configuration, while passive proxies are polled by the server, so confirm which direction your firewalls allow before choosing. Start with one server and one database if your estate is single-site and your restart window is acceptable. Add HA when server loss is unacceptable, and add proxies or proxy groups when remote links or collection load are the constraint, then review the Zabbix high availability documentation before you design the database layer.
Zabbix single server, HA cluster and proxies side by side
This table compares a single Zabbix server, the native HA cluster and proxies or proxy groups across topology, database, failover, buffering, upgrades, licensing and operating effort. Read each row as a question to answer for your own sites, since the right model usually combines a few of these pieces rather than picking one.
| Factor | Single server | HA cluster with proxies |
|---|---|---|
| Server topology | One server node collects, processes and serves the frontend | Several server nodes: one active, the others stand by running only the HA manager |
| Shared database | One database used by the server | All HA nodes use the same database, so the database needs its own redundancy design |
| Failover timing | No automatic server failover | Failover delay configurable from 10 seconds to 15 minutes, default one minute; a cleanly stopped node is replaced within 5 seconds |
| Data buffering at sites | Proxies, if used, store collected data locally during short outages | Proxies store data locally and send it to whichever HA node is active |
| Proxy groups | Proxies can be used without grouping, so each proxy's hosts stay fixed | Zabbix 7.0 and later proxy groups redistribute hosts when a proxy goes offline |
| Database requirements | Supported server databases include MySQL, MariaDB or PostgreSQL with optional TimescaleDB | Same server database support; proxies must use their own separate database, and SQLite is allowed only for proxies |
| Upgrade coordination | One server to upgrade and one database schema to manage | Database replication must be in sync during upgrades, so confirm the procedure before each release |
| Licensing | AGPL-3.0 from Zabbix 7.0, no license fee and no device limits | Same AGPL-3.0 licensing; paid support tiers apply to either model |
| Operating effort | Lower: one server, one database, and fewer components to patch | Higher: HA nodes, database redundancy, proxies and their databases must be run and tested together |
How active and standby server nodes share one database
A Zabbix HA cluster is one active server node with standby nodes behind it, and every node reads and writes the same database. The cards below cover what the standby nodes do, how the frontend and data senders find the active node, and what the database layer still has to provide.
One active node collects data
Only the active node collects and processes monitoring data. Each HA node is a separate server process, so the team must decide which node runs as the first active node and confirm in the Zabbix HA node list that the expected node is active after startup. Test the cluster by stopping the active node and checking that collection resumes on another node under the configured failover delay.
Standby nodes run only the HA manager
Standby nodes run only the HA manager. They do not collect or process data and do not listen on ports, so they add no direct load on monitored hosts and expose no extra listening endpoints. Confirm with your security team that port scans and firewall rules treat standby nodes as non-listening, and that monitoring of the cluster itself checks each node's status rather than only the active one.
All nodes share one database
Every HA node connects to the same database, so the database is the single point of shared state for configuration, history and node status. The Zabbix HA documentation says the native solution has no specific database requirements, which means database redundancy, replication and failover must be designed separately. Ask the database team which layer provides high availability and how it is tested, and confirm that replication stays in sync during Zabbix upgrades.
Frontend finds the active node
The web frontend locates the active node by reading the database nodes table, so users do not need to know which HA node is currently active. This makes the nodes table a dependency for the UI as well as for collection. Check that the frontend connects to the same database as the server nodes and that a failover is reflected in the UI within the expected window during your own test.
Proxies and agents list every node
Proxies and agents are configured with the names of all HA nodes, not one address. They send data to whichever node is active at the time. Confirm that every HA node name is listed in each proxy and agent configuration, that names resolve from every network segment, and that a node added later is included in those lists before it is ever promoted.
What HA leaves to the database layer
The native Zabbix server high availability cluster manages which node is active, but it does not make the database redundant. All nodes in the cluster use the same database, and the Zabbix high availability documentation states that the native solution has no specific database requirements. That means a failover of the Zabbix server node can succeed while the database behind it is a single point of failure. Before you add HA nodes, decide how the database will be made redundant, whether through replication, a managed service or clustering your team already operates, and design that layer separately from the Zabbix configuration. The documentation also warns that database replication must be in sync during upgrades, so include the replication state in your upgrade runbook and confirm it before each server node is upgraded.
The timing settings in the HA layer are the ones to review with the database team. The failover delay is configurable from 10 seconds to 15 minutes, with a default of one minute, and it is the time a silent active node is tolerated before a standby takes over. A node that stops cleanly is replaced within 5 seconds, and each node updates its last access time every 5 seconds. A short failover delay speeds recovery but can trigger a failover during a slow database query or a brief network interruption, so test the delay against your real database latency under load. Ask your database team how long a connection or query can stall before it is treated as an outage, and set the failover delay above that figure.
Zabbix 7.4 supports MySQL or Percona 8.0.30 to 9.7, MariaDB 10.5 to 12.3, PostgreSQL 13 to 18 and the TimescaleDB extension 2.13 to 2.29, as listed in the Zabbix requirements. The database you choose drives the redundancy design: PostgreSQL with TimescaleDB, MySQL or MariaDB each have their own replication, failover and backup tooling, and the tooling you already run in production is usually the safest choice. Confirm the exact supported versions for your target Zabbix release in the requirements page before you pick a database, because the supported ranges differ by version.
Which setup fits which environment
A single Zabbix server is usually the right starting point when all monitored hosts sit in one site, a short interruption in alerting is acceptable, and the team can restore the server from its own backups within the window it already commits to internally. The server, its database and the web frontend are one set of moving parts, which keeps design, upgrades and troubleshooting simple. Redundancy is not free: an HA cluster adds nodes, shared database design and a failover process your team must test.
- Simpler upgrades: one server and one database mean one upgrade path and one rollback plan to rehearse.
- Lower operating surface: there is no failover behavior to validate, monitor and explain during an incident.
- Adequate when the window is tolerable: this holds when a restart of a few minutes does not breach an internal alerting expectation.
- Database still matters: a single server does not remove the need for backups and tested restores of the Zabbix database.
- Revisit when the window shrinks: if an outage in alerting becomes a business or audit concern, the single-server assumption needs to be re-examined.
Before deciding, confirm with your operations leads how long alerting can be unavailable and whether that expectation is written into any internal control or service commitment.
When monitored hosts sit in several sites connected by links that drop or slow down, a central server polling everything across the WAN is fragile. A Zabbix proxy collects data on behalf of the server and stores what it gathers locally before sending it, so a short communication outage does not lose data. Adding proxies is usually the first step for distributed estates, and it addresses the link problem more directly than a server HA cluster does.
- Local collection: a proxy at each site keeps polling local devices even when the central server cannot be reached.
- Buffered delivery: data collected during a short outage is sent once the link returns, which matters for capacity and trend reporting.
- Active or passive mode: active proxies connect to the server and pull configuration, while passive proxies are polled by the server, so firewall rules can be designed around the site.
- Separate database per proxy: each proxy needs its own database, which adds maintenance at every site.
- Confirm the buffer and the link profile: check how long your sites can be cut off and whether that fits the buffering behavior documented for your Zabbix version.
Proxies protect collection at a site, but they do not make the central server itself highly available. Decide that separately if the central server is a dependency for alerting.
When the number of monitored devices grows into the thousands, the central server and its database carry the processing load. Proxies offload collection from the server, so the server handles configuration, processing and alerting for work that proxies have already collected. Proxy groups add load distribution on top of that: monitored hosts are redistributed between proxies automatically, which avoids manually rebalancing assignments as the estate changes.
- Offloaded collection: proxies take over polling for their assigned hosts, reducing direct load on the server.
- Automatic redistribution: in Zabbix 7.0 and later, proxy groups move hosts between proxies when one goes offline, for load balancing and high availability.
- Database sizing: data volume grows with item count and history retention, so the database layer needs planning regardless of server topology.
- Plan the grouping: a group only helps if the proxies have enough capacity to absorb reassigned hosts.
- Test with real load: ask the vendor or your implementation partner for a load test against your own item counts rather than relying on general guidance.
Confirm your expected item count, polling intervals and history retention before choosing between a single server with proxies and an HA cluster behind them.
A team that cannot accept a monitoring gap should evaluate the native Zabbix server HA cluster. Several server nodes share one database, one node is active and the others stand by. Standby nodes run only the HA manager, so they do not collect or process data. The failover delay is configurable from 10 seconds to 15 minutes, with a default of one minute, and a node that stops cleanly is replaced within 5 seconds. Proxies and agents list all HA node names, so they send data to whichever node is active.
- Failover is not instant: the configured failover delay determines how long monitoring is interrupted when the active node fails unexpectedly.
- Database redundancy is separate: the HA solution has no specific database requirements, and database replication must be kept in sync during upgrades, so you must design it yourself.
- Frontend follows the active node: the frontend finds the active node from the database nodes table.
- Upgrade discipline: keep replicas consistent during upgrades, and rehearse the procedure before production.
- Set the delay deliberately: a shorter delay speeds failover but raises the risk of switching on a transient fault.
Confirm your required recovery expectations with your operations and security leads, then test the failover delay and database failover in a non-production environment.
How proxies buffer data and offload the server across sites
A Zabbix proxy collects data on behalf of the server, which makes it the main tool for offloading the server across sites. Each proxy stores collected data locally before sending it, so a short outage between a site and the server loses no data. Proxies also suit sites with unreliable communications or thousands of devices. The decision to add proxies is separate from the decision to add an HA cluster: an HA pair protects the server, while proxies protect the data path from remote sites. A proxy must use its own separate database, so budget for one database per proxy and plan its backups and sizing alongside the server's. Check with the Zabbix proxy documentation which database engines your proxy version supports for your sizing.
Active and passive proxies work in opposite directions, and the choice affects firewall rules. An active proxy connects to the server and requests its configuration, so only outbound connections from the site are needed. A passive proxy is polled by the server, which means the server must reach the proxy on its listening port. Many regulated sites prefer active proxies because they avoid inbound rules into the segment. Confirm the connection direction, the port and the certificate handling with your network and security teams before you pick a mode for each site.
From Zabbix 7.0 onward, proxies can be placed in a proxy group. The server automatically redistributes monitored hosts among the proxies in the group for load balancing, and when a proxy goes offline its hosts move to the remaining members for high availability. Test this in a non-production environment with your real host counts, because the effect on each remaining proxy's database and collection load depends on your sizing. SQLite is supported only for Zabbix proxies, not for the server, so it can be considered for small remote proxies but never for the central database. Confirm the SQLite limits for your version in the requirements documentation before you use it.
Planning upgrades around LTS windows and database sync
This sequence confirms a target Zabbix release against its support dates, protects the shared database, and aligns proxies so that an HA cluster and its proxy estate upgrade without losing monitoring coverage or data.
Confirm the target release against the life cycle policy
Start by choosing the target Zabbix version from the life cycle and release policy. Zabbix 7.0 LTS has full support until June 30, 2027, and limited support until June 30, 2029. Zabbix 8.0 LTS is planned for Q4 2026 with full support to Q4 2029. Standard releases come out every 6 months and get 12 months of support, while LTS releases come out every 1.5 years and get five years of support. Record the target version, its end-of-full-support date and the date your team plans to move again. Done when the change record names one version and its support dates, and the owner has checked them against the current policy page.
Read the release notes and confirm the upgrade order
Read the release notes and upgrade instructions for the target version and confirm the exact sequence with Zabbix documentation and your own environment before any change. Note any database requirement changes, supported database versions in the requirements page, and any change to proxy compatibility. Your team, with the DBA and the Zabbix owner, should write down the order of database, server nodes, frontend and proxies. Done when the runbook lists each component with its target version and an approved order signed off by the owners.
Verify the database layer and replica sync
The Zabbix HA model does not manage the database. All nodes use one database, and the HA docs warn that database replication must be in sync during upgrades. Your DBA confirms that the primary and every replica are healthy, replication lag is within your agreed tolerance, and backups are restorable. Confirm the database version is within the supported range for the target release, for example PostgreSQL 13 to 18 for Zabbix 7.4. Done when the DBA signs off on replication status, a fresh backup has been tested by restore, and the rollback point is recorded.
Take backups and snapshots of every node
Before the first change, take a full database backup and configuration backups for each server node, the frontend and each proxy. Where your platform supports it, snapshot the virtual machines or containers as well. The owner of each node confirms the backup location and that a restore has been rehearsed in a non-production copy. Done when every node has a named backup that the team can restore from, and the rollback steps list which backup applies to each component.
Upgrade standby nodes and the database schema in sequence
Plan the server upgrade so that the active node is not changed while it is handling data. Follow the order in your runbook, which usually means upgrading standby nodes first and confirming they run the new code without collecting data. Only one node should run the database schema upgrade. Keep the failover delay in mind, because the default is one minute and it can be set from 10 seconds to 15 minutes. Done when the standby nodes report the target version, the HA node list shows the expected roles, and the schema check passes in the logs.
Align proxy versions with the server
Plan the proxy estate next. Proxies that collect data for many hosts should move to a version your runbook has matched to the server release, using the compatibility notes from the release documentation. Proxies in a proxy group should be upgraded in a rolling order so that hosts stay monitored while other proxies take them over. Confirm each proxy reports the new version, its queue of buffered data is draining, and the hosts it monitors are reporting again. Done when every proxy version is recorded, and the monitoring team confirms no site has a gap in its data.
Verify failover, data flow and frontend access
After the upgrade, test the HA behavior. Confirm that the frontend finds the active node through the nodes table, that agents and proxies send data to the active node, and that a controlled stop on the active node fails over within the delay you configured. Check that data is arriving with no gaps and that the frontend and API work for operators. Done when a failover test is recorded with the time it took, the monitoring team confirms current data across sites, and the change record is closed.
Record the outcome and plan the next window
Close the change by documenting what changed, the final version of each component, backup locations, any issues, and the date of the next planned window. Compare the target version with the support dates from the life cycle policy so the team knows when the current LTS line stops receiving full support. Confirm this plan with the release notes for the next target. Done when the record is filed, the next review date is on the team calendar, and the owners agree on which version and support window the estate will run.
Backups, monitoring and skills each model needs
This table compares what a single Zabbix server and a native HA cluster with proxies each ask your team to maintain day to day. Read each row as a question to answer for your own environment, since the operating load depends on your database design, site count and change process. The main takeaway is that HA moves the server role to a clustered design but leaves database redundancy, proxy database care and upgrade coordination with your team.
| Operating task | Single server | HA cluster with proxies |
|---|---|---|
| Database backup and replication | One database to back up and restore, with recovery tested against the server's own schema | Shared database becomes the single point of failure, so its replication and backups must be designed separately from Zabbix HA |
| Failover testing | Not applicable, but restore from backup must still be rehearsed | Test failover with the configured delay (10 seconds to 15 minutes, default one minute) and confirm the frontend and agents reach the new active node |
| Proxy database maintenance | Not applicable unless proxies are added later | Each proxy needs its own database, so backups, housekeeping and disk growth must be managed for every proxy |
| Upgrade coordination | One server and one database to upgrade in a planned window | Nodes, proxies and the database must be upgraded in a sequence, and database replication must stay in sync during upgrades |
| Monitoring the platform itself | Monitor the server process, database health and queue backlog from one place | Monitor active and standby node status, database replication lag, proxy availability and buffered data volumes |
| Failover and proxy group behavior | Not applicable | Confirm how proxy groups redistribute hosts when a proxy goes offline and test the load on remaining proxies |
| In-house skills | Zabbix administration, database operations and backup restore | Zabbix administration plus database replication, proxy operations, load balancer or DNS design and upgrade planning |
| Evidence to ask a vendor or partner for | Backup and restore runbook, tested restore record | Written failover test results, replication design, proxy database backup plan and upgrade runbook |
Questions buyers ask before choosing a Zabbix deployment model
What does a single Zabbix server cost to run compared with an HA cluster?
A single server is the lower-cost starting point because it needs one server host, one database and one set of maintenance tasks. Zabbix open source carries no license fee, no device limits and no feature gates, so the recurring spend is infrastructure, database operations, staff time and any paid support. An HA cluster adds server nodes that share one database, so the cost grows with node count, load balancing of the front end and database redundancy, which Zabbix does not supply. Paid support is priced by tier, from Silver (8x5 with a 1 day response) to Global (24x7 with a 1 hour response), according to the Zabbix support page. Ask any quote to itemize hardware, database redundancy, proxy sites and the support tier separately.
How long does a Zabbix HA failover take?
Failover time is set by the configured failover delay, which ranges from 10 seconds to 15 minutes with a default of one minute, according to the Zabbix high availability documentation. A node that stops cleanly is replaced within 5 seconds, and nodes update their last access time every 5 seconds. Shorter delays fail over faster but react more readily to a slow node that is not actually down. Test the delay in your own environment with realistic database latency before relying on a value for alerting continuity.
Does Zabbix HA protect the database too?
No. Zabbix HA covers the server nodes only. All nodes use the same database, and the Zabbix HA documentation states that the native solution has no specific database requirements. Database redundancy, such as replication, failover and backups, has to be designed separately, and the documentation warns that replicas must be in sync during upgrades. Budget and assign ownership for the database layer in the scope, because a single database that fails takes every server node with it.
When do proxies make sense, and what do they cost to run?
Proxies suit sites with unreliable links or thousands of devices. A proxy collects data on the server's behalf, stores it locally so short outages lose no data, and must use its own separate database. Each proxy site therefore adds a host, a database and patching work. Active proxies connect to the server and request configuration, passive proxies are polled by the server, and proxy groups from Zabbix 7.0 onward redistribute hosts when a proxy goes offline. Ask for the proxy count, site connectivity assumptions and database choice in writing, since these drive most of the added cost.
How long does a migration to HA or proxies take?
No figure for migration duration is supplied for this comparison, so treat any timeline as unknown until scoped. The duration depends on the number of hosts, templates and custom items, the database size and migration path, whether an existing single server is upgraded in place, the number of proxy sites to deploy, and the test windows the team requires. Zabbix standard releases come out every 6 months and LTS releases every 1.5 years, so upgrade timing also affects planning, according to the Zabbix life cycle and release policy. Ask for a timeline that lists each phase and its dependencies.
Can our own team run an HA cluster with proxies?
Yes, if the team can operate a database cluster, patch several server nodes and proxies on a consistent schedule, and monitor failover. The skills needed go beyond Zabbix itself because database redundancy is outside the Zabbix HA scope. Teams that lack database operations experience often need a support tier with a short response window, such as Gold (4 hour response) or higher, or an outside implementation partner. DeployOpen implements, hardens, backs up, upgrades, documents and supports self-hosted platforms in the client's own infrastructure, and most engagements are fixed-scope and retainers are available for ongoing support.
What should a written scope for a Zabbix HA project include?
A written scope should name each component and who owns it:
- Server node count, failover delay and the test plan for failover
- Database platform and version, its redundancy design, backup and restore tests
- Proxy sites, proxy type (active or passive), proxy groups and each proxy database
- Upgrade approach against the Zabbix life cycle, including which release is targeted
- Support tier, response window and what the operating team must handle
Also request deliverables, acceptance criteria and a timeline tied to those items. Confirm the Zabbix version in use and the supported database versions against the Zabbix requirements before committing.
How DeployOpen scopes and delivers Zabbix deployments
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so a Zabbix deployment is designed around your sites, database and network. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- Inventory monitored host counts, sites, links and how often each site loses connectivity to the core.
- Confirm which database platform and redundancy design you already run, since HA leaves database availability to you.
- Write down failover tolerance, proxy placement and which teams receive alerts before any build begins.
How we build
- Install and configure the server, HA nodes or proxies in your cloud accounts, data centers or air-gapped networks.
- Deploy each proxy with its own separate database and tune the failover delay against your tested recovery expectations.
- Test node stops, proxy outages and database failover in staging before any production cutover.
How we hand over
- Deliver architecture diagrams, runbooks for node replacement and proxy recovery, and the configuration record for your team.
- Document the upgrade sequence, including keeping database replicas in sync before each Zabbix upgrade.
- Walk your operators through alert routing, backup restores and the checks they run after a failover.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan upgrades around the Zabbix release and support windows so your LTS line stays within full support.
- Confirm with Zabbix which paid technical support tier fits your response requirements, since DeployOpen does not resell that support.
