New Relic vs Zabbix: which fits a host and network monitoring need
If your main problem is server health, network devices and host availability rather than application traces, the first question is which product matches that work. New Relic fits teams that want a hosted APM product and a single observability service covering applications, infrastructure and logs. Zabbix fits teams that want a self-hosted infrastructure monitor, released under AGPLv3 from version 7.0, with no license fee, no device limits and no feature gates on the open-source software. Your choice turns on whether you need application depth or infrastructure breadth, and how much of the operating burden you want to keep in house.
New Relic bills on data ingested, with 100 GB per month free, and it charges by user type, so host and network metrics count toward the same ingest pool as application telemetry. Zabbix shifts cost into servers, databases and staff time. Before you decide, count your device and sensor volume, the number of people who need console access, and the retention you actually need. Confirm the current Zabbix version and its support window on the Zabbix life cycle and release policy page, because standard releases are supported for 12 months while LTS releases get longer support.
Four questions should settle the decision: how much APM depth you need, whether telemetry must stay in your own data center, who will operate the Zabbix server and database, and whether you will buy Zabbix technical support. Zabbix offers paid support tiers, and its high availability and proxy groups need deliberate design. Ask your team to map each question to an owner and a cost line before you compare quotes.
Which option fits which monitoring scenario
This table maps common monitoring scenarios to the platform that usually fits better, with the reason for each. Read it against your own mix of infrastructure, network, APM and compliance needs, since most teams land on one platform for infrastructure and another for application traces. Zabbix support subscriptions are optional, and every row assumes you can run Zabbix without buying one.
| Scenario | Better fit | Reason |
|---|---|---|
| Server and network monitoring only | Zabbix | Zabbix covers hosts, network devices, triggers and notifications with agents, SNMP and templates, and it has no per-GB or per-user fee to run. |
| APM plus infrastructure | New Relic or an OpenTelemetry stack | Zabbix does not provide distributed tracing or APM depth, so application traces need Jaeger, SigNoz or a Grafana stack alongside it. |
| Strict data residency | Zabbix | Zabbix runs entirely on servers you choose, so metrics and host inventory stay in your own data center or air-gapped network. |
| Small ops team | New Relic, if you accept the bill; otherwise Zabbix with a single server | Zabbix needs someone to maintain the server, database, upgrades and templates, so plan that time before choosing it for a thin team. |
| Need for a vendor support contract | Zabbix with a support subscription, or New Relic | Zabbix support tiers are optional and sold separately, so a team that can staff its own upgrades may not need one. |
| Large fleet across several sites | Zabbix with proxies and proxy groups | Proxies collect data locally and proxy groups redistribute hosts when a proxy goes offline, which suits distributed networks. |
| Server uptime requirement | Zabbix with its high availability cluster | Zabbix server HA uses a shared database with standby nodes; confirm failover timing and database design in your own test before relying on it. |
| Per-user access by many engineers | Zabbix, with access controlled by its user roles | Zabbix has no per-user platform fee, though you should confirm its authentication options against your identity provider. |
Where the data lives and who controls it
New Relic is a hosted service, so your telemetry sits in the regions it operates and under its contractual controls. Zabbix runs inside your own data center or cloud account, which moves control of data location, access and retention to your team and makes the evidence your responsibility.
Hosted regions versus your own servers
New Relic stores telemetry in the regions it offers, so data location is set by your account configuration and contract rather than by your own hardware. A Zabbix server, its database and its proxies run wherever you deploy them, whether on premises or in a cloud account you control. Check which New Relic region your account uses, confirm it with New Relic in writing, and map every Zabbix component to a named site, subnet and backup location.
AGPLv3 from Zabbix 7.0
Zabbix 7.0 and later are released under AGPLv3, while every version up to 6.4 remains GPL-2.0. Mixing versions across a fleet or an upgrade path therefore mixes license terms. Have legal review how the AGPLv3 network-use clause applies if you modify Zabbix and offer it to users over a network, and record the exact version and license for each deployment.
Authentication and identity options
New Relic user access is managed inside its platform with its own user types and roles. Zabbix supports its own internal accounts and external authentication, which lets you tie access to an existing directory and enforce your password and session policies. Confirm which authentication methods your Zabbix version supports, document how administrator accounts are protected, and test that removing a user in your directory removes Zabbix access.
Data retention and deletion control
With New Relic, retention periods follow the plan and data types you buy, and deletion is requested through the vendor. In Zabbix, history and trend retention are set per item, and the database holds everything in your environment, so you decide what is kept and purged. Define retention per data class, decide how long event and audit records must survive, and document how deletion requests are fulfilled across backups.
Audit trail and access evidence
Assessors will ask who changed a trigger, who viewed sensitive hosts and who ran a script. Zabbix keeps its own configuration and action records in the database, but you must export, retain and protect them with your logging stack. For New Relic, request its audit and access records and confirm retention in your contract. Define the evidence list before the assessment starts so you know which records to pull.
Who prepares the evidence
DeployOpen plans, configures and documents controls for Zabbix and prepares the evidence an assessment will request, under a written fixed scope. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform the assessment, so ask them which records and configurations they expect before implementation starts.
What the Zabbix license change means for your team
The key point for procurement is that the Zabbix license depends on the version you run. From Zabbix 7.0 onward, Zabbix is released under the GNU Affero General Public License version 3 (AGPLv3). All versions up to 6.4 were released under the GNU General Public License version 2 (GPL-2.0). A deployment standardized on 6.4 or earlier and one on 7.0 or later therefore carry different license obligations, and your inventory should record the exact version on every Zabbix server, proxy and agent so the license position is traceable.
Zabbix states that its open source software has no license fee, no device limits and no feature gates. That is a vendor statement, so ask your legal team to read it against the current license text on the Zabbix license page before you write it into a policy. AGPLv3 is the part to review carefully. Its network-use clause can apply when you modify Zabbix and let users interact with the modified version over a network, such as a customized web interface or an internal portal built on Zabbix code. Legal should decide whether your planned customizations trigger source-sharing duties, and whether any internal-only use changes that answer.
Paid technical support is a separate purchase from the license. Zabbix sells support subscriptions in several tiers, and the license terms do not change based on whether you buy one. Ask your counsel and your procurement lead to confirm the license text for the exact release you plan to deploy, and to document the decision in the same record as your version pinning. Revisit that decision whenever you plan an upgrade across the 7.0 boundary.
How cost of ownership splits between New Relic and Zabbix
New Relic bills by data ingested, measured in GB regardless of data type, and it includes 100 GB ingested per month free according to New Relic's pricing and billing documentation. Users are billed by type: Basic, Core and Full platform are the three billable user types. Core Compute is a consumption option that the same documentation describes as unlimited users, with charges based on queries, alerts and API calls. For infrastructure monitoring, ingest volume is the main driver, so host count, metric frequency, log volume and retention settings all move the bill.
- Per-GB ingest: Charges scale with everything your agents and integrations send, not only with the hosts they watch.
- Monthly free allowance: The 100 GB ingested per month free applies before ingest charges, so the net bill depends on how far your volume exceeds it.
- User types: Basic, Core and Full platform carry different costs, and the mix of engineers and read-only viewers changes the total.
- Core Compute: Consumption pricing based on queries, alerts and API calls replaces a fixed user model, so automation and dashboard load affect cost.
- One-time dashboard rebuild: Recreating dashboards, alert conditions and notification routing in New Relic is project work, and it recurs only when you change the monitoring design.
Ask New Relic for a quote built on your current ingest, user type mix and Core Compute assumptions, and confirm which features each user type includes.
Zabbix software has no license fee, no device limits and no feature gates, according to Zabbix's support page, so the recurring cost is the infrastructure and people that run it. You provision the Zabbix server, a database from the supported list (MySQL or Percona, MariaDB, or PostgreSQL with TimescaleDB), and proxies where remote sites or large device counts require them. Paid technical support is optional and comes in Silver, Gold, Platinum, Enterprise and Global tiers.
- Servers and database: Hardware or cloud instances for the server, database and storage are paid by you, and their size follows device count, item count and polling intervals.
- Proxies and storage: Proxies add machines per site, and history and trend retention determine disk growth, which is usually the largest recurring infrastructure line.
- Staff time and upgrades: Standard releases arrive every 6 months with 12 months of support, and LTS releases arrive every 1.5 years with 5 years of support, so plan recurring upgrade windows against that cadence.
- Support tiers: Silver offers 8x5 support with 1 day response, Gold 4 hour response, Platinum 2 hour response, Enterprise 1.5 hour response and Global 1 hour response, both 24x7 in those higher tiers.
- Drivers: Device count, polling intervals, item counts and retention periods push server, database and storage costs up, while fewer items or longer intervals lower them.
Ask Zabbix or a partner for a quote that states the support tier, response time and the hardware assumptions behind your device count and retention.
Migration and setup costs are mostly one-time, while subscriptions, infrastructure and upgrades recur. In a New Relic setup, the recurring line is usage-based and moves with ingest and users. In Zabbix, the recurring lines are infrastructure, upgrade effort and any support subscription, and the one-time lines are installing, building templates, and recreating triggers and notifications.
- One-time costs: Template design, trigger and notification rebuilds, and validation against your current alerts are project work that you should scope in writing.
- Recurring costs on New Relic: Ingest and user charges continue for as long as the account runs, and they rise as telemetry grows.
- Recurring costs on Zabbix: Compute, storage, backups, upgrade effort and optional support continue, and they track device count and retention.
- Parallel running: Running both platforms during cutover doubles some costs for a period, so include that overlap in both estimates.
- Support decisions: A support subscription is a choice, not a requirement, and it changes the recurring line directly.
Before comparing totals, check whether your current New Relic bill includes items beyond infrastructure monitoring, because those will not disappear on migration.
The same inventory can produce very different totals on each platform, so the drivers matter more than any headline figure. For New Relic, the variables are ingest volume, user mix and query or alert load under Core Compute. For Zabbix, the variables are the number of monitored devices and items, polling intervals, history and trend retention, and how many proxies the topology needs. Neither side's total should be computed from one metric.
- Device count: More hosts raise both ingest on New Relic and item volume on Zabbix, so model them in the same unit.
- Polling intervals: Shorter intervals multiply stored values on Zabbix and ingested metrics on New Relic.
- Retention: Longer history on either side increases storage, and on New Relic it can also affect plan choices.
- Users and access: On New Relic, the user type mix sets cost. On Zabbix, access is managed in the web interface, with authentication options documented by Zabbix.
- High availability: A Zabbix HA cluster or proxy groups add nodes and database capacity, which is a cost you choose to carry.
Request a sizing worksheet from each vendor or partner that uses your device count, polling intervals, retention and user list, and compare the outputs line by line.
How a move from New Relic infrastructure monitoring to Zabbix proceeds
The sequence turns host, network and alerting coverage from New Relic into a Zabbix server that your team operates, validated in parallel before cutover. APM traces follow a separate path and are planned on their own track.
Inventory hosts, checks and alert conditions
Export the list of monitored hosts, the infrastructure checks, dashboards and alert conditions currently running in New Relic, and note which are owned by which team. Separate server, network and host data from APM and browser telemetry, because only the first group maps to Zabbix. Confirm with the New Relic account owner which telemetry is sent by agents and which arrives over OTLP, since those paths behave differently during migration. The step is done when every host and check has an owner and a classification, and the APM scope is agreed as a separate track.
Map alerts to Zabbix triggers and notifications
Translate each New Relic alert condition into a Zabbix trigger expression, a severity, and a notification action that routes to the same people or channels. Record where a New Relic condition has no direct equivalent and needs a redesigned threshold or a Zabbix item calculation. Review the mapping with the on-call owners, who confirm that escalation paths still reach them. The output is a signed-off mapping table that lists each source condition, its Zabbix trigger, and any gaps that remain open.
Build templates and host groups
Group hosts by role, location and owner, then build Zabbix templates that hold the items, triggers, discovery rules and dashboards shared by each role. Keep templates in version control so changes are reviewed and traceable. Test each template on a small set of representative hosts before wider rollout. The step is complete when each host group has a template that the owning team has reviewed and that produces the expected items and triggers on test hosts.
Deploy the Zabbix server, database and proxies
Install the Zabbix server with a supported database backend, such as MySQL, MariaDB, PostgreSQL or PostgreSQL with TimescaleDB, using the versions in the Zabbix requirements for the release you select. Place proxies near remote sites or network segments, and decide whether to run a high availability server cluster or proxy groups for failover. Configure authentication through the method your identity team approves. The step is done when the server, database, proxies and failover design pass acceptance tests that your team has written and run.
Deploy Zabbix agents and enroll hosts
Install Zabbix agents on the hosts in scope, or use agentless checks where agents cannot be installed, and point them at the correct proxy or server. Agent data from New Relic does not transfer to Zabbix, so each host starts a new history and dashboards begin from zero. Enroll hosts in batches and confirm that items are collecting, triggers evaluate, and no host is left without a template. The step is done when every in-scope host reports to Zabbix and its monitoring status matches the inventory.
Run New Relic and Zabbix in parallel
Keep New Relic alerts active while Zabbix triggers and notifications run against the same hosts. Compare alert events from both systems for an agreed observation period, and record each mismatch with its cause, such as a threshold difference, a missing item, or a notification routing error. Fix mismatches in Zabbix and repeat the comparison until the on-call owners accept the results. The step is complete when the parallel run shows no unexplained gaps in agreed critical alerts.
Cut over alerting and decommission New Relic infrastructure
Switch notifications for the in-scope hosts to Zabbix, disable the matching New Relic alert conditions, and keep a documented rollback path for the cutover window. Archive dashboards and exported configuration that you need for audit or reference, and remove New Relic agents from hosts once their data is no longer required. Keep New Relic APM agents and their OTLP exports on their separate track until that migration is planned. The step is done when Zabbix sends all in-scope notifications, New Relic infrastructure alerts are disabled, and the archive is stored under your own control.
Questions buyers ask before choosing Zabbix over New Relic
What drives the effort of moving from New Relic infrastructure monitoring to Zabbix?
The effort depends mostly on how many hosts, network devices and checks you monitor, how many New Relic alert conditions and dashboards you have built, and how much of that work is tied to agents you can replace directly. Each host needs a Zabbix agent or an SNMP or agentless check, and each trigger, notification and dashboard must be rebuilt by hand because no automated converter exists. Costs are mostly one-time labor for inventory, template design, rebuilding alerts and validation, plus recurring server and database operations. Ask any partner for a written scope that lists hosts by type, alert conditions, dashboards and integrations before agreeing on a quote.
How long does a move to Zabbix take, and what changes the timeline?
No general duration is supported by published figures, so treat any number you hear as an estimate to be tested against your own estate. The timeline is set by the number of monitored systems, the variety of device types, how many alerting paths must match existing on-call routing, and whether you run both monitoring stacks in parallel during cutover. Teams with a clean inventory and mostly standard Linux and Windows hosts usually finish faster than teams with many custom integrations. Ask for a phased plan with a parallel-run period and explicit acceptance criteria for each phase.
Can our internal team migrate to Zabbix without outside help?
Yes, many teams do this in-house, because Zabbix is open source and its documentation covers agents, templates, proxies and high availability. The practical question is whether your staff have time and skill for the full rebuild, including server sizing, database maintenance, upgrades and alert tuning. Outside help is most useful for a fixed-scope piece such as architecture design, template migration, hardening or a documented cutover. DeployOpen plans, implements, hardens and documents self-hosted platforms in your own infrastructure under a written scope, and it can support the work as a retainer afterward.
What skills and staff time does running Zabbix require?
Plan for people who understand Linux administration, databases, network protocols such as SNMP, and monitoring concepts such as triggers and dependencies. Someone must own the server, the database backend (MySQL, MariaDB, PostgreSQL with TimescaleDB, or the other supported options), proxies and backups, and patch the platform on the standard release cadence. Recurring staff time depends on the size of the estate, the number of proxies and whether you run high availability. Ask your team to estimate the monthly operating load before choosing, and confirm the supported database versions for the Zabbix release you plan to run.
Does Zabbix cover application performance monitoring the way New Relic APM does?
No. Zabbix is strongest at server, network, and infrastructure monitoring, with templates, discovery, proxies and alerting. New Relic APM provides code-level transaction traces, service maps and application-specific dashboards, which Zabbix does not replicate. If APM is part of your use case, plan a separate tracing stack, such as OpenTelemetry instrumentation sent to Jaeger or a Grafana stack, and keep Zabbix for infrastructure. Confirm which APM features your teams actually use before deciding that Zabbix alone replaces New Relic.
Do we need a Zabbix support subscription to run it in production?
No. Zabbix states that its open-source software has no license fee, no device limits and no feature gates. Paid technical support subscriptions are optional and come in Silver, Gold, Platinum, Enterprise and Global tiers, with different support hours and response times. Choose a tier based on how quickly you need vendor-backed help, and weigh it against the cost of in-house or partner expertise. Confirm current tier terms directly with Zabbix before budgeting.
How does the AGPL license change affect internal use of Zabbix?
Zabbix moved from GPL-2.0 to AGPL-3.0 starting with version 7.0, and versions up to 6.4 remain GPL-2.0. The AGPL is designed for software offered over a network, so legal review matters if you modify Zabbix and let users interact with the modified version, or if you distribute it in a product. Running an unmodified Zabbix server for your own staff is the common case, but counsel should confirm your obligations for your specific use. Also consider the lifecycle: Zabbix 7.0 LTS receives full support until 30 June 2027, and 6.0 LTS limited support ends on 28 February 2027.
Where DeployOpen fits when you evaluate or move to Zabbix
The first step with DeployOpen is a written evaluation scope that tests Zabbix against your actual monitored estate before any migration decision is made. We would inventory the hosts, network devices and services that New Relic currently covers, identify which of them need agents, SNMP or other collection methods, and record which dashboards and alert conditions are used in practice. That scope, along with deliverables and timelines, is agreed in writing before work starts, so the output is a decision document rather than a verbal assessment. Your team stays in control of the decision, and DeployOpen does not publish prices. A quote follows from the written scope.
Implementation happens inside your own infrastructure, in your cloud accounts, data centers or air-gapped network. Typical work covers a high availability server cluster sharing one database, proxies or proxy groups placed by network segment, and templates built for your device types with triggers and notification rules rebuilt from the New Relic alert conditions. We harden the deployment, including the web frontend authentication settings, database access and service accounts, and we document the configuration, backup approach and upgrade path so your staff can operate it. Ask any implementer to show the database and proxy sizing behind the design, and confirm which Zabbix release line you intend to run, since support windows differ between standard and LTS releases.
Migration support is delivered as a fixed-scope project, with optional retainers for ongoing upgrades, backup testing and continuous monitoring of the platform after cutover. A retainer is usually the right choice when the platform will grow beyond the initial scope, while a one-time project suits a defined estate. Zabbix support subscriptions from Zabbix itself are a separate purchase and cover vendor technical support, so ask in the quote whether you want that contract alongside DeployOpen's services, and confirm the tier with Zabbix directly. DeployOpen does not hold partner status with Zabbix, and any support contract you buy is between you and Zabbix.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For a New Relic to Zabbix move, that work covers the Zabbix server and its database, the proxy layout that keeps monitored networks reachable, the high availability cluster or proxy groups you choose, agent and template rollout, trigger and notification rebuilds, and the backup and upgrade routine for the Zabbix 7.0 LTS or later line you standardize on. Security testing and compliance readiness work can run alongside the build, so the systems, access controls and evidence an assessor will ask for are in place early. DeployOpen prepares that evidence, but independent auditors and certification bodies are the ones who issue any audit report or certification.
Start the conversation with a written inventory rather than a product decision. List the New Relic infrastructure agents and integrations you run, the hosts and network devices each covers, the alert conditions and notification channels tied to them, and the dashboards your operations team relies on. Confirm which Zabbix support tier you expect to need, since the Zabbix support page lists tiers from Silver to Global with different coverage hours and response times, and confirm the license position for your use under the AGPLv3 terms that apply from Zabbix 7.0 onward. DeployOpen can turn that inventory into a fixed-scope plan with deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. Quotes follow from the written scope, and DeployOpen does not publish a price list.
