Datadog or Zabbix: when each option fits
Choose Datadog when you want one hosted platform for infrastructure metrics, APM and logs, and choose Zabbix when your main job is server, network and host monitoring on infrastructure you run yourself. Datadog fits teams that want application traces, log analytics and infrastructure views in a single vendor-operated service and are comfortable paying per host and per data volume. Zabbix fits teams that need deep device and host monitoring, want no license fee or device limits, and have the staff to run the server, database and proxies. Zabbix does not cover APM or log analytics, so a team that needs distributed traces or log search will still need a second tool next to it.
A per-host billing review or a data residency question usually starts the evaluation, so begin by counting. List how many hosts and network devices you monitor today and how many you expect in 12 months, and separate the ones that need application-level tracing from the ones that only need availability, CPU, memory, disk and interface metrics. If most of the estate is infrastructure, Zabbix covers that need directly. If APM and logs drive the bill, a Zabbix-only plan leaves you with a gap to close. Check the Zabbix life cycle and release policy before you pick a version, because standard releases are supported for 12 months and LTS releases for 5 years.
Then decide the operating model. Zabbix requires your team to run the server, a database from the supported list, proxies and upgrades, and the high availability and proxy load balancing features add design work of their own. Ask who will own those tasks, what hours they can cover, and whether a paid support tier from Zabbix or an implementation partner such as DeployOpen fits the budget. Datadog moves that operation to the vendor but keeps data in its regional sites, so confirm with Datadog which site your telemetry would use and whether that satisfies your residency rules. The right answer depends on these four points, not on feature lists alone.
Which scenarios favor Datadog and which favor Zabbix
This table maps common operating scenarios to the platform that fits them better and names the condition that would change the answer. Read each row against your own estate, skills and data rules, since the right choice often depends on one or two constraints rather than on feature lists. Zabbix covers host, server and network monitoring with no license fee, while Datadog covers that plus APM and logs as a hosted service with per-host and per-volume billing.
| Scenario | Better fit | Reason and what would change the answer |
|---|---|---|
| Host-heavy estate with SNMP and network devices | Zabbix | Zabbix monitors servers, network gear and SNMP devices natively with no device limits in its open source edition. Datadog bills per host, so a large fleet of hosts raises recurring cost. Confirm which device types and SNMP versions your estate needs. |
| One tool for APM, traces and logs | Datadog | Datadog brings infrastructure, APM and log analytics into one hosted product. Zabbix does not cover APM or log analytics, so you would add Jaeger, SigNoz or a Grafana stack and Loki to match it. |
| Monitoring data must stay on your own servers | Zabbix | Zabbix runs entirely in your infrastructure. Datadog is hosted in regional sites that do not share data across each other, so confirm whether its chosen site satisfies your residency rule before relying on it. |
| Team already skilled in Zabbix | Zabbix | Existing templates, proxies and triggers carry over, which lowers retraining effort. The answer changes if the team lacks staff to run and upgrade the server, database and proxies. |
| Team wants vendor-run hosted operations | Datadog | Datadog removes server, database and upgrade work from your staff. Zabbix requires your team to operate the server, database and proxies, or to buy support or a partner for that work. |
| Strict need for vendor support SLAs | Datadog | Zabbix sells paid support tiers with response targets, so Zabbix can meet this need too. Compare the tier response times against what your service agreements require before deciding. |
| Large distributed sites with failover needs | Zabbix | Zabbix offers a native server high availability cluster and proxy groups that redistribute hosts when a proxy goes offline. Confirm the design against your recovery targets and database setup. |
| Zabbix licensing change is a concern | Depends on your policy | Zabbix 7.0 and later are AGPLv3, while earlier versions remain GPL-2.0. Ask your legal team whether AGPL obligations fit your distribution and hosting model before adopting it. |
Where monitoring data lives and who operates it
Datadog keeps telemetry in the regional site you choose, operated by the vendor, while Zabbix runs inside your own network under your own operations. The cards below cover the placement, licensing, access and evidence questions that usually decide which model a regulated team can accept.
Datadog hosted regional sites
Datadog runs its backend in separate regional sites, including US1, US3, US5, EU1, AP1, AP2, UK1, US1-FED and US2-FED. Datadog's documentation states that each site is completely independent and data cannot be shared across sites, so the site chosen at onboarding fixes where telemetry is stored. Check which site your organization uses, whether it matches your residency obligations, and whether a site change would require re-onboarding.
Zabbix in your own infrastructure
Zabbix server, database, web frontend and proxies run on hardware or virtual machines you control, so monitoring data stays inside your network boundary. Your team owns patching, database backups and capacity planning for the server and database tier. Confirm which database engine your standards allow, because the supported options are listed in the Zabbix requirements.
AGPLv3 terms from Zabbix 7.0
Zabbix moved from GPL-2.0 to AGPL-3.0 starting with version 7.0, while versions up to 6.4 remain GPL-2.0. Under AGPL terms, a modified version offered to users over a network may require you to make the corresponding source available. Have legal counsel review any custom modules, forks or embedded changes before you deploy them in a customer-facing service.
Authentication and access options
Zabbix provides its own user accounts and role-based permissions in the web frontend, and its authentication documentation describes the supported login methods. Confirm in that documentation whether LDAP, SAML or other external methods fit your identity provider before you design the rollout. Plan how administrator accounts, API tokens and proxy credentials will be stored and rotated.
Compliance evidence and audit scope
DeployOpen can prepare controls, configurations and evidence for a self-hosted Zabbix deployment, such as access settings, backup records and change logs. DeployOpen does not issue audit reports or certifications. Independent auditors and certification bodies make that determination, so ask them early which evidence they expect and whether it covers the Datadog or Zabbix environment.
Operating effort: running Zabbix versus using Datadog
A small team monitoring one data center or a handful of cloud accounts can usually run a single Zabbix server, a supported database and the web frontend on a single node. The work is installation, template selection, agent rollout, user and authentication setup, backups of the database, and regular upgrades. Datadog removes the server, database and agent-hosting work, but the team still configures agents, tags, monitors and dashboards, and pays per host as the estate grows. Zabbix has no per-host licence fee, so the recurring cost is mostly staff time and infrastructure, plus any paid support you choose.
- Server and database: You install and patch the Zabbix server, frontend and database (PostgreSQL with TimescaleDB, or MySQL or MariaDB, all within the versions listed in the requirements page).
- Agents and templates: You deploy Zabbix agents and assign official or custom templates to hosts.
- Backups: You schedule and test database backups, since history and configuration live there.
- Access: You set up user groups and authentication for the frontend.
- Datadog side: Datadog runs the backend, so your work is agent deployment, tagging and monitor configuration.
Confirm with your own estate size and staff plan which of these tasks your team already performs for other systems.
An estate spread across sites, branches or network segments usually places Zabbix proxies close to the monitored hosts, so collection continues locally and the central server receives the data. Since Zabbix 7.0, proxy groups automatically redistribute monitored hosts between proxies for load balancing and high availability when a proxy goes offline. This reduces manual reassignment, but you still design the proxy layout, size each proxy, and maintain one proxy per site or group. In Datadog, you would deploy Agents per site and rely on the vendor's regional sites for storage and processing, with the data residency implications described elsewhere on this page.
- Proxy design: You decide how many proxies exist, where they run and which hosts each one monitors.
- Proxy groups: Groups rebalance hosts when a proxy goes offline, so you need to confirm capacity headroom on the remaining proxies.
- Proxy upgrades: Proxies must be kept on a version compatible with the server, so each upgrade touches every site.
- Network paths: You own the firewall rules and certificates between proxies and the server.
- Datadog side: Agents still need outbound connectivity to the chosen Datadog site, and you choose that site when you deploy.
Ask your Zabbix partner or vendor to confirm proxy sizing guidance for your host counts before you commit to a layout.
Where monitoring must survive a server failure, Zabbix offers a native high availability cluster: several server nodes share one database, one node is active and the others stand by. Failover happens when the active node exceeds a configurable failover delay, which the documentation sets between 10 seconds and 15 minutes. The team owns the database high availability design, the node sizing, the failover testing and the choice of delay. Datadog's hosted backend is operated by the vendor, but your own agents, collectors and alert routing still need redundancy on your side.
- Database HA: The shared database becomes the critical dependency, so you own its replication, failover and backups.
- Node configuration: You deploy and keep every server node on the same version and configuration.
- Failover delay: You pick the delay within the documented range and test it against your alerting expectations.
- Testing: You rehearse node failures and record the results as evidence for your own assurance reviews.
- Datadog side: The vendor operates the backend, but you still own agent redundancy and how alerts reach your on-call staff.
Confirm the supported database HA topology with the Zabbix documentation before you design it.
Zabbix publishes two release tracks. Standard releases come out every 6 months and are supported for 12 months. LTS releases come out every 1.5 years and are supported for 5 years, with three years of full support and two years of limited support. Zabbix 7.0 LTS was released on 4 June 2024 with full support until 30 June 2027 and limited support until 30 June 2029. Zabbix 7.4 was released on 1 July 2025, with full support until Zabbix 8.0 LTS and limited support until Q1 2027. Zabbix 6.0 LTS limited support ends on 28 February 2027. Zabbix 8.0 LTS is planned for Q4 2026. Choosing a track determines how often your team performs an upgrade and rehearses rollback.
- LTS track: Fewer upgrades, with a longer support window that suits teams with limited change capacity.
- Standard track: More frequent upgrades, with a shorter support window that requires steady upgrade work.
- Support dates: 6.0 LTS limited support ends 28 February 2027, so plan migrations from that version before then.
- Paid support: Zabbix sells Silver to Global tiers, which can shift some upgrade and incident load to the vendor.
- Datadog side: Datadog ships platform changes on its own schedule, so you do not schedule backend upgrades.
Confirm current dates and planned releases on the Zabbix life cycle page before you set a maintenance calendar.
The clearest way to compare operating effort is to list each function and say who performs it. With Zabbix, your team owns the server, database, proxies, agents, templates, upgrades, backups, access control and evidence of all of these. With Datadog, the vendor operates the hosted backend and UI, while your team owns agent deployment, tagging, monitors, dashboards, and the choice of regional site. Zabbix does not cover APM or log analytics, so those functions need separate tools, each with its own operating work. Costs shift from per-host subscription to staff time, infrastructure and optional support.
- Zabbix owned by you: Server, database, proxies, agents, templates, upgrades, backups and authentication.
- Datadog operated by the vendor: Backend, storage, UI availability and platform upgrades.
- Datadog owned by you: Agents, tags, monitors, dashboards, and site selection.
- Scope gap: APM and log analytics require a different stack in both cases if you need them on Zabbix.
- Support options: Zabbix technical support is paid and tiered, while Datadog's support terms are part of its subscription.
Ask for a written responsibility matrix from any implementation partner before the design is final.
How a move from Datadog infrastructure monitoring to Zabbix proceeds
The sequence turns Datadog host monitoring into a Zabbix design with its own templates, proxies and alerting, cut over group by group. APM and logs move separately, so the Datadog Agent is replaced rather than converted.
Inventory hosts, checks, dashboards and alerts
Export the list of monitored hosts, tags, integrations, custom checks, dashboards and monitors from Datadog. The team that owns each host group confirms which checks matter and which are unused. Dashboard definitions can be exported as JSON for reference. Done when every monitored host and every active monitor is mapped to an owner and a business purpose, and the team has agreed which items are in scope for Zabbix and which stay on Datadog or another tool.
Separate APM and log scope early
Record which Datadog features are not infrastructure monitoring: APM traces, log management, Synthetic tests, RUM and on-call. Zabbix does not provide APM or log analytics, so these need their own tools and their own migration plan. Done when the scope document names a separate destination for each out-of-scope feature, so the Zabbix project does not absorb workloads it was not designed for.
Design the Zabbix server, database and proxies
Architects size the Zabbix server, choose a supported database and plan the proxy layout by network segment and site. They confirm the database version against the Zabbix requirements for the release chosen, and decide on a high availability cluster and proxy groups where uptime needs it. Done when a written design covers server nodes, database, proxies, storage, authentication and backup, and the vendor or internal team has confirmed the release and its support window.
Build templates and discovery rules
Engineers translate each Datadog integration and custom check into Zabbix templates, items, triggers and low-level discovery rules. Standard templates cover many common platforms, but each one should be reviewed against what the Datadog check actually collected. Done when a test host in each category produces the expected items and triggers, and the template set is version controlled with a named owner.
Run Zabbix alongside Datadog
For a defined set of hosts, both agents or collectors report at the same time, so operators can compare values, alert timing and gaps. Where applications already emit OpenTelemetry metrics, the same telemetry can be sent to both backends during the overlap. Done when the team has reviewed a full period of comparable data, documented every difference and resolved the gaps that matter for alerting.
Cut over by host group
Move hosts in groups that share an owner, a network segment or a proxy, not all at once. For each group, Zabbix alerting becomes authoritative, notification routing is switched and the Datadog monitors for those hosts are disabled after sign-off. Done when each group has a recorded cutover, its on-call contacts have confirmed alerts reach them, and a rollback path has been tested.
Decommission Datadog Agents and monitors
After all in-scope groups are cut over and the retention period agreed for historical data has passed, remove the Datadog Agent from each host and disable the related integrations and monitors. Keep dashboard exports and alert definitions as documentation. Done when no in-scope host reports to Datadog, the agent removal is recorded per host, and the remaining Datadog services are listed with their own migration plans.
Questions buyers ask before switching from Datadog to Zabbix
Can Zabbix replace Datadog APM?
No. Zabbix monitors servers, network devices, hosts and their services through agents, SNMP, and item checks, but it does not provide distributed tracing, service maps or code-level transaction views the way Datadog APM does. For that layer, instrument applications with OpenTelemetry and send traces to a self-hosted backend such as SigNoz or a Grafana and Jaeger stack. Keep Zabbix for infrastructure health and alerting, and treat APM as a separate workstream with its own scope. Confirm the exact trace and profiling features you rely on in Datadog, because some have no direct open-source equivalent.
How much effort does moving from Datadog infrastructure monitoring to Zabbix take?
Effort depends mostly on how many hosts, checks and dashboards you have, and how many Datadog monitors carry business logic. The main drivers are the number of custom integrations that need a Zabbix template, the alert rules that must be rebuilt with their escalation paths, and whether you need a proxy layer across network segments. Running both platforms in parallel during cutover adds work but reduces risk. Ask any implementation partner for a written scope that lists hosts, templates, dashboards and alert rules separately, so the quote follows from the inventory rather than from an estimate.
What does our team need to provide for a Zabbix migration?
You need an inventory of what Datadog monitors today, access to the Datadog account for exporting dashboard definitions and monitor configurations, and people who know which alerts matter to operations. You also need owners for the Zabbix server, database and proxies, including backup and patching responsibilities. On the engineering side, expect to supply hosts for the Zabbix server and proxies, network access from monitored segments, and a decision on how credentials for monitored systems are stored and rotated. Finally, name a person who signs off on alert behavior, since alert noise and missed alerts are the most common cutover problems.
Can our own staff do the Zabbix migration, or do we need a partner?
Many teams with Linux and database experience can run a Zabbix deployment themselves, using the official documentation and their own templates. A partner is worth considering when the inventory is large, when you must meet audit evidence requirements, or when no one has time to rebuild alerts and dashboards while keeping production running. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure under a fixed-scope written agreement, and offers retainers for ongoing upgrades. Your internal team remains responsible for alert decisions and business sign-off.
How long does a Datadog to Zabbix switch take?
The duration depends on scope: host count, number of custom checks, the amount of Datadog dashboard and monitor logic to rebuild, network segmentation and the size of the parallel-run window your change board requires. Zabbix release timing does not set this; choose a supported version and plan the cutover around your own change calendar. Ask for a timeline in the written scope, with milestones for inventory, build, parallel run, cutover and decommissioning. Any date quoted before the inventory is complete should be treated as provisional.
What do Zabbix paid support tiers add if the software is free?
Zabbix states that its open source software has no license fee, no device limits and no feature gates. Paid technical support subscriptions are a separate purchase that adds vendor response commitments. The tiers are Silver, Gold, Platinum, Enterprise and Global, with coverage ranging from 8x5 support with a 1 day response at Silver to 24x7 support with a 1 hour response at Global. Compare those response times with your operational needs and your internal on-call capacity, and confirm current terms directly with Zabbix before you commit.
How does the AGPLv3 license change in Zabbix 7.0 affect us?
From Zabbix 7.0 onward, Zabbix is released under AGPLv3, while versions up to 6.4 remain under GPLv2. For internal monitoring use, most organizations run Zabbix without distributing it, so the practical concern is whether you modify Zabbix and make it available to users over a network, which AGPLv3 can require you to share. Have your legal or compliance team review your specific use, especially if you ship custom modifications or offer monitoring as a service to others. Staying on 6.x is possible, but it is out of standard support, so plan any upgrade against the published life cycle dates.
When Zabbix needs outside help and when it does not
An internal team can usually run Zabbix alone when it already operates Linux servers, a relational database and a configuration management tool, and when the monitored estate sits in one or two sites with a stable set of host types. In that setting the work is routine: install the server and web frontend, attach a proxy where a network segment needs one, import or adapt the standard templates, and tune item intervals and triggers as the environment changes. Zabbix does not charge a license fee or impose device limits, so the main recurring costs are staff time and infrastructure. The decision point is whether your team has someone who can own the database, the backups and the upgrade calendar. The LTS and standard release cadence described in the Zabbix life cycle and release policy means upgrades recur, and each one needs a tested rollback plan.
An implementation partner adds the most value where the design decisions are expensive to reverse. Typical examples are template design that follows your naming, tagging and ownership model rather than vendor defaults, a multi-site proxy topology with proxy groups that can absorb a failed proxy, and a server high availability cluster backed by a hardened database. Database hardening, backup and restore testing, and a dated upgrade plan that matches the support windows in the life cycle policy are also common scopes. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, and this work is agreed as a fixed scope in writing before it starts, so you know the deliverables and the handover documents in advance.
Before you engage anyone, confirm three things in writing: which Zabbix version and support tier you will run, who is accountable for paid technical support and its response times, and whether your current staff can meet the database and backup requirements in the Zabbix requirements. Ask any partner to show the exact scope of templates, proxies, database work and upgrade steps, and to name the documents you will keep after handover. If your team can answer those questions and has run a restore drill, you may not need outside help at all. If it cannot, a bounded engagement that ends with documented runbooks is usually the cheaper path.
How DeployOpen helps evaluate, implement or migrate Zabbix
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Datadog vs Zabbix decision can be tested against your actual hosts, network devices and proxies before anything moves. Work starts from a written scope, and the deliverables are agreed before any build begins.
How we scope
- Inventory hosts, network devices, cloud accounts and the Datadog Agent footprint that a Zabbix deployment would replace.
- Agree in writing which monitoring use cases move to Zabbix and which stay on Datadog or move to other tools.
- Define the proxy layout, database choice and high availability design that fit your sites and failure domains.
- Record cost components, staffing assumptions and the questions to put to Zabbix support tiers during quoting.
How we build
- Deploy Zabbix server, database, web frontend and proxies in your own cloud accounts, data centers or air-gapped networks.
- Rebuild host groups, templates, triggers and notification routing, and test each alert against known failure conditions.
- Configure authentication, access roles and TLS settings, then run security testing against the deployed monitoring platform.
- Run Zabbix in parallel with Datadog during cutover so alert behavior can be compared before any monitor is retired.
How we hand over
- Deliver architecture diagrams, runbooks, configuration exports and a template inventory mapped to your former Datadog monitors.
- Document backup, restore, upgrade paths and the Zabbix release life cycle dates your team must plan around.
- Train operators on proxy management, template changes and troubleshooting before the Datadog subscription is ended.
- Provide evidence packs that support your compliance assessors, while noting that independent auditors issue any formal attestation.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Plan upgrades around the Zabbix standard and LTS release cycle, with a retainer covering version changes and regression checks.
- Confirm with Zabbix which paid support tier fits your response-time needs, since DeployOpen is not a Zabbix partner or reseller.
- Scope any APM or log analytics work separately, because Zabbix does not cover those areas on its own.
