PRTG Freeware alternatives for teams that have hit the 100-sensor limit
Once monitoring grows past PRTG Freeware's limit of 100 sensors, roughly 10 devices, the decision is between buying a PRTG 500 subscription and moving to a free self-hosted platform. The license fee can be removed with Zabbix, Checkmk Community or LibreNMS, but setup time, hosting and day-to-day operations become the real cost. Zabbix states that its open source software has no license fee, no device limits and no feature gates. Before comparing options, count your sensors by device, not by device type. A single Windows server with CPU, memory, disk and service checks can use several sensors on its own, so the 100-sensor ceiling is often reached sooner than the device count suggests.
The device mix decides which platform fits. Servers and applications monitored through agents and templates point toward Zabbix, which is licensed under AGPL-3.0 from version 7.0 onward. Network estates made up mainly of switches, routers and bandwidth links point toward LibreNMS, which auto-discovers SNMP devices and is covered by the GPLv3 license. Windows-heavy and mixed estates point toward Checkmk Community, which is described as free and open source for small infrastructures, easily scalable to about 100 hosts. Beyond that size, the Checkmk editions page lists Pro from 190 euros per month, billed annually, so the free tier has a practical ceiling you should plan around. Confirm the host counts and agent requirements against your own environment before you choose.
Free software moves the cost to people and infrastructure. You pay for the server, the database, backups, upgrades and the staff who maintain templates and alert rules. Paid support is optional: Zabbix's technical support tiers run from 8x5 with a one-day response (Silver) to 24x7 with a one-hour response (Global), so ask what response level your operations need. Before you let the PRTG 500 subscription lapse, confirm its renewal and end dates with Paessler and export your sensor data. Ask any implementation partner for a fixed written scope covering migration, templates, notifications and handover.
What the sensor limit forces you to decide
Outgrowing PRTG Freeware is less about one missing feature than about a set of operating choices. The six decisions below connect: the scale you plan for shapes the architecture, the architecture shapes the support and ownership model, and all of them affect what it costs to run.
Sensor and device growth
Count what you monitor today and what you expect in twelve months, split by device type, since SNMP switches, Windows servers and application checks load the platform differently. Freeware's limit of 100 sensors and about 10 devices is the trigger, not the target. Ask whether your sensor count is growing by new hosts or by more checks per host, because that determines whether you scale the server, the database or the polling layer first.
Paid support or community only
Zabbix states that its open source software has no license fee and no device limits, so the real question is whether your team will carry incidents alone. Zabbix sells technical support in Silver, Gold, Platinum, Enterprise and Global tiers, with response times that differ by hours of coverage. Checkmk Community is free but has no vendor support tier. Decide the required response window before you choose a path, and ask the vendor for the terms in writing.
High availability for the monitoring server
Monitoring that goes dark during an outage is the failure you most need to avoid. Zabbix offers a native high availability cluster where several server nodes share one database, with one active and the others on standby. Confirm the failover delay you can accept, and confirm that the database itself has a recovery plan, because the cluster does not remove that dependency.
Remote sites and proxies
Branch offices and data centers often sit behind firewalls or on slow links, so polling them directly from a central server is rarely the right design. Zabbix proxies collect locally and report back, and proxy groups from Zabbix 7.0 onward redistribute hosts when a proxy goes offline. Map each remote site to a proxy or proxy group before you plan the migration, and confirm which sites need their own proxy for resilience.
Notifications and reporting needs
Freeware alerts and reports rarely reflect what operations teams actually use. List who gets paged, through which channels, and which reports leadership or auditors need, then check each one against the target platform. LibreNMS offers alerting through transports such as mail and Slack and traffic billing reports, while Checkmk Pro and Ultimate add advanced reporting and automation. Confirm each required notification path in a proof of concept before you retire PRTG alerts.
Who owns the platform after launch
A self-hosted monitoring platform needs a named owner for patching, template maintenance, database backups, upgrades and onboarding of new hosts. Zabbix 7.0 LTS has full support until 30 June 2027, so plan upgrade windows against the vendor's life cycle dates. Decide whether internal staff, a managed service or a DeployOpen retainer will carry this work, and write that ownership into the handover documentation before cutover.
Zabbix, Checkmk Community and LibreNMS compared against the sensor limit
This table compares how Zabbix, Checkmk Community and LibreNMS handle the sensor limit that ends PRTG Freeware, along with license terms, scaling, install paths and trade-offs. Use the first two rows as a shortlist filter: they show whether a free option fits your device count and estate type. The PRTG 500 subscription is the paid comparison point, and its price must be confirmed with Paessler before you compare total costs.
| Criterion | Zabbix | Checkmk Community | LibreNMS |
|---|---|---|---|
| Removes the 100-sensor limit | No device limits or feature gates in open source; confirm sizing for your polling load | Suited to about 100 hosts; larger estates need a paid edition | Scales by adding polling capacity; confirm limits for your device count |
| License terms | AGPL-3.0 from 7.0; GPL-2.0 for 6.4 and earlier | GPL-2.0 source; Community is free and open source | GPLv3, with exceptions for bundled third-party packages |
| Scaling and high availability | Native server HA cluster on a shared database; proxy groups rebalance hosts from 7.0 | Distributed monitoring requires Pro or a higher paid edition | Distributed polling supported; design high availability with the project docs |
| Agent and SNMP coverage | Agent and SNMP monitoring with templates you build and maintain | Agent-based checks; push-mode agents need a paid top-tier edition | SNMP auto-discovery across network hardware; limited beyond network devices |
| Install paths | Confirm packages and supported database versions for your OS and Zabbix release | Linux packages for RHEL, SLES, Debian, Ubuntu, or Docker images | Needs PHP 8.4, MariaDB, NGINX or Apache and Python 3; Docker image available |
| Support and community | Paid support subscriptions, Silver to Global tiers, from 8x5 to 24x7 | Pro adds 8x5 support; confirm response terms with Checkmk | Community project with forum and Discord; confirm any paid support separately |
| Automation API | Confirm API coverage for your automation needs in the Zabbix docs | Confirm automation options for your edition before you plan | API v1 documented as beta; plan for changes before relying on it |
| Trade-offs | Broad coverage and no feature gates, but you build and tune templates yourself | Fits small mixed estates; growth or push agents push you toward a paid edition | Strong for switches, routers and bandwidth; application checks are outside its focus |
Where the cost moves from license fees to setup time
With the free options, the license line on the budget drops to zero, and the money moves into people, infrastructure and time. Zabbix states that its open source software has no license fee, no device limits and no feature gates, and Checkmk Community and LibreNMS are also free to download and run. What you pay for instead is the server and database that run the platform, the staff who build templates or discovery rules, the migration of sensors and thresholds, and the ongoing upgrades and backups. Those costs recur every year, while template design and the first migration are largely one-time, although they grow with each new device class you add. Optional paid support is the one cost that can be bought directly. Zabbix sells technical support subscriptions in tiers from 8x5 Silver with a 1 day response, through 4 hour response at Gold, up to 24x7 Global with a 1 hour response, so a quote should state the tier, the hours and the response time it covers. The Checkmk editions page lists Pro at 190 euros per month billed annually, which includes 8x5 support, but confirm current pricing with Checkmk before you build a budget on it. For a PRTG 500 comparison, the subscription quote follows from your device and sensor count, so ask Paessler for that figure and set it beside your own estimate of staff hours.
Effort rises with the size and shape of the estate more than with the software choice. Sensor count drives the number of templates, items and checks to validate. Custom sensors, meaning scripts or vendor-specific counters that PRTG users built by hand, must be rewritten as Zabbix items, Checkmk plugins or LibreNMS polling, and each one needs its own test. Application checks such as database queries, web transactions or middleware health usually take longer than SNMP interface polling because they need credentials, timeouts and thresholds tuned to each application. The number of sites matters too: every remote location may need a Zabbix proxy or a Checkmk distributed site, plus a network path and a monitoring account for it. Before you choose, inventory your PRTG sensors by type, count the custom ones and identify which sites have no local collector. Then ask each vendor or partner to price the work against that list, including who writes the templates, who runs the migration and parallel-run period, and who owns upgrades and restores after go-live. An outside partner can take fixed-scope work on any of these items, but the budget should show which parts your own team keeps.
Which free option fits which estate
Zabbix fits estates where the monitoring scope spans servers, databases, network devices and application checks in one tool. Its templates, agent and SNMP coverage, and low-level discovery let one team watch Linux, Windows, databases and network gear without a second product. Zabbix has no license fee, device limits or feature gates, so the recurring cost is the infrastructure and the people who run it, plus an optional support subscription.
- Broad coverage: agent, SNMP, IPMI and custom item checks sit in one server, so application and host metrics share the same alerting.
- Scaling out: proxies collect from remote sites, and proxy groups redistribute hosts when a proxy goes offline.
- Native high availability: several server nodes share one database, with failover after a configurable delay of 10 seconds to 15 minutes.
- Templates to maintain: you own the template library, so expect to adapt or write templates for internal applications.
- Licensing change: from Zabbix 7.0 the code is AGPL-3.0, so confirm that this fits how you distribute or modify it.
Question to answer first: do application checks and database metrics matter more to you than network-only views? If yes, Zabbix is the stronger starting point. Confirm the supported database versions and the Zabbix release cycle against the Zabbix life cycle policy before you pick a version.
Checkmk Community suits estates where most monitored systems are Windows servers and workstations, and where an operator wants a web interface, service discovery and agents without building templates from scratch. Its editions page describes Community as free and open source monitoring for small infrastructures, easily scalable up to about 100 hosts. Beyond that size, plan for the commercial editions or a different tool.
- Discovery: automatic service discovery fills in checks for each host once it is added.
- Agents: the agent route is available in Community, but push-mode agents and automatic host registration are Ultimate features.
- Installation: Community installs as Linux packages on Red Hat-based systems, SUSE, Debian and Ubuntu, or as a Docker image.
- Scale ceiling: the host guidance of about 100 is a hard planning limit for free use, not a soft target.
- Core: Community runs on the Nagios core, while the commercial editions default to the Checkmk Micro Core.
Question to answer first: do you have about 100 hosts or fewer, and will you need push agents or mass rollout within a year? If not, price the Pro or Ultimate editions alongside Community before you start the migration. Confirm current edition limits on the Checkmk editions page.
LibreNMS fits network teams whose PRTG use centers on switches, routers, firewalls and interface bandwidth. It is an auto-discovering, SNMP-based system that covers a wide range of network hardware and collects routing and switching data such as BGP, OSPF, STP, VLAN, ARP and FDB tables. It also offers traffic billing by quota or 95th percentile and integrates device backup with Oxidized and RANCID.
- Discovery: SNMP auto-discovery builds the device inventory from the network itself.
- Routing and switching data: STP, OSPF, OSPFv3, BGP and forwarding tables are collected, which PRTG sensors rarely cover in depth.
- Billing and bandwidth: traffic billing and 95th percentile reports serve capacity and chargeback work.
- Limited application scope: it does not cover application checks or server internals in the way Zabbix or Checkmk do, so keep a separate tool for those.
- API: API v1 is documented as beta, so review its stability before you automate against it.
Question to answer first: is routing protocol data and bandwidth billing more important to you than application or server checks? If yes, LibreNMS may be enough on its own. Confirm the supported operating systems against the install guide and the GPLv3 licensing against your distribution model.
How to deploy Zabbix or LibreNMS without outgrowing the platform again
This sequence sizes the platform to your device and sensor counts, pins a supported release line, and runs the new monitoring alongside PRTG until alerts match, so the next growth step is planned rather than forced.
Size the server and database to your count
Start from the number of devices, sensors or hosts you expect in 12 to 24 months, not today's PRTG count. Your team, not a vendor, decides this, and the output is a written sizing note listing CPU, memory, disk and database choice for the central server. For Zabbix, check the requirements page for the supported database versions before you buy hardware or request virtual machines. Ask your platform or hosting team to confirm the storage growth rate against your polling interval, because history retention drives disk use more than sensor count alone.
Choose a supported Zabbix LTS line
For Zabbix, pick a Long Term Support release rather than a standard one if you want the longest maintenance window. Zabbix 7.0 LTS was released on 4 June 2024 with full support until 30 June 2027 and limited support until 30 June 2029, according to Zabbix's life cycle policy. Zabbix 6.0 LTS limited support ends on 28 February 2027, so a new deployment should not start on that line. The output is a recorded version decision with its end-of-support dates in your change log. Confirm current release status on the life cycle page before you install.
Select a database from the supported list
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, according to Zabbix's requirements page. Your DBA or database team picks one, checks it against your backup tooling and standards, and confirms the TimescaleDB option if you expect large history volumes. The check is complete when the chosen engine and versions appear in the install plan and a test instance has been created and backed up once. Confirm the pairing for the exact Zabbix version you select.
Add proxies or a proxy group for remote sites
Place a Zabbix proxy in each remote network segment, data centre or branch where polling crosses a slow or restricted link, so the central server does not carry every poll. From Zabbix 7.0, proxy groups redistribute hosts automatically when a proxy goes offline, so group proxies in the same site where failover makes sense. Your network team documents firewall rules for the proxy-to-server port and the agent connections. Done means each proxy shows as online in the frontend and hosts assigned to it return data.
Configure server high availability if needed
If the monitoring service must survive a server outage, configure Zabbix's native high availability cluster, where 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 between 10 seconds and 15 minutes, according to Zabbix's HA documentation. Your platform team sets the delay to match how quickly you need alerts to resume, and tests a planned failover in a non-production window. Done means a documented failover test completes and alerts still fire from the standby node.
Run discovery in parallel with PRTG until alerts match
Keep PRTG running while the new platform discovers the same devices and builds equivalent checks. Compare alert behaviour for the same fault across both systems, including thresholds, notification routing and maintenance windows. The check is complete when the team has recorded a set of test failures and each one raised the same alert, on the same recipients, in both tools. Keep PRTG as the source of record until the operations lead signs off the parity list.
Deploy LibreNMS on a supported OS or Docker
For a network-focused deployment, check the LibreNMS install guide for supported systems, which include Ubuntu 24.04 and 26.04, Debian 12 and 13, and RHEL derivatives such as Rocky Linux, AlmaLinux and Oracle Linux 8 to 10. The guide requires PHP 8.4 or newer, MariaDB, NGINX (recommended) or Apache, and Python 3. Alternatively, the librenms/librenms image on Docker Hub packages the application for container hosts. Your platform team picks one path, and the check is a completed auto-discovery run that lists your switches and routers with their interfaces.
Install Checkmk and choose the edition
For Checkmk, install either the Linux packages for Red Hat-based systems, SUSE Linux Enterprise Server, Debian or Ubuntu, or the Docker container image, which the setup guide supports for Community and commercial editions. Community is free, open-source and scales to about 100 hosts. Choose Pro or Ultimate only if you need a feature in the editions list, such as distributed monitoring, push-mode agents or automatic host registration, which the editions page places in higher tiers. The output is a documented edition decision with the license cost, if any, recorded against the expected host count.
Schedule upgrades against support windows
Write an upgrade calendar that uses the Zabbix standard release cadence, where standard releases come out every 6 months and are supported for 12 months, and the LTS cadence, where releases come out every 1.5 years with 5 years of support. Add the LibreNMS release process and the Checkmk patch releases to the same calendar. Assign one owner for each platform and a test environment that receives upgrades first. The calendar is complete when every platform has a named owner, a target version and a date for the next review against its end-of-support date.
What proof of monitoring coverage reviewers ask for
Once PRTG sensors are replaced by Zabbix, Checkmk or LibreNMS, the people who signed off on monitoring will ask what it covers, who is alerted, and whether it survives a failure. The cards below are the artifacts that answer those questions. They are inputs to an independent assessment, not a substitute for one.
Device and sensor inventory with owners
List every monitored device, service and check, with a named owner and the business system it supports. Compare the inventory against the PRTG export so that no device or sensor silently drops out during the move. Reviewers often start here because an inventory without owners cannot show who is accountable when an alert fires. Keep the inventory under version control or in a system with change history, and date each review.
Alert thresholds and notification records
Record each alert threshold, its severity, the escalation path and the channel used, such as mail or Slack. Keep a log of test notifications and of real alerts with acknowledgement times. Reviewers check that thresholds were rebuilt deliberately rather than copied by guesswork from PRTG sensor settings. Confirm that the notification transports you configure are the ones your on-call staff actually receive.
Backup and restore tests for the monitoring database
A backup that has never been restored is not evidence. Document the database backup schedule, the storage location and the retention period, then record at least one full restore into a separate environment with the time it took and the checks you ran afterward. For Zabbix, this covers the shared database; for Checkmk and LibreNMS, the site or MySQL/MariaDB data and configuration. Ask your vendor or support provider which files must be included.
Upgrade and support calendar
Record the version you run, its support end date and the planned upgrade window. Zabbix publishes full and limited support dates for each LTS and standard release, so a reviewer can see when a version leaves support. Note whether you rely on community support or a paid subscription, and keep the vendor's life cycle page with the record. Checkmk and LibreNMS releases should be tracked the same way, with the chosen release noted and the change approved.
High availability failover test results
Show that monitoring keeps working when a component fails. For Zabbix, this means a test of the server cluster failover delay and of proxy groups redistributing hosts when a proxy goes offline. Record the test date, what was switched off, how long monitoring took to recover and whether alerts still fired. A failover that was only designed, not tested, will raise questions in most reviews.
Access control settings for the monitoring interface
Export the user roles, group permissions, authentication method and administrator list for the monitoring interface, and show how they map to the people in the inventory owner list. Record whether accounts are tied to your central identity provider, how multi-factor authentication is handled and how leavers are removed. Reviewers commonly ask whether anyone can change thresholds or silence alerts without a record. Check the authentication options in the Zabbix documentation or the equivalent guide for your chosen platform.
Questions buyers ask before moving off PRTG Freeware
How much does moving off PRTG Freeware cost compared with the PRTG 500 subscription?
Open-source Zabbix and Checkmk Community carry no license fee, so the cost is in people, servers, storage and support, and the PRTG subscription is replaced by those recurring components. Costs rise with device count, sensor volume, number of sites, high availability design and how many hours your staff spend on upkeep. As an illustrative example, Checkmk's editions page lists Pro at 190 euros per month billed annually, and that price buys advanced reporting, distributed monitoring and 8x5 support, so it is one of several paths to compare. Confirm the current PRTG 500 subscription price directly with Paessler, then ask each candidate for a written scope that lists the hardware, database, staff hours and any support tier you would need.
How long does it take to set up Zabbix, Checkmk or LibreNMS after Freeware?
Setup time depends on what you are monitoring, not on the product name alone. The main drivers are the number of devices, how many custom sensors or checks you need to rebuild, how many sites or proxies you run, and how many notification rules and dashboards must match what PRTG does today. A flat network of switches and routers that relies on SNMP discovery takes less work than a mixed estate with Windows agents, application checks and several remote locations. Ask each vendor or partner for a written plan that breaks the work into discovery, template or rule mapping, alert testing, backup and a parallel run period, and ask which tasks depend on your device list being exported first.
Can our own team run the migration without outside help?
Yes, a team can do it in-house if it has solid Linux administration and SNMP skills, and someone who can own the platform after go-live. The work needs people who can install the chosen stack on a supported distribution, configure SNMP credentials and discovery, build or adjust templates, design alert routing and secure the web interface and database. LibreNMS's install guide, for example, lists Ubuntu 24.04 and 26.04, Debian 12 and 13 and RHEL derivatives among its supported systems, and it needs PHP, MariaDB, a web server and Python. Be honest about who will patch, back up and upgrade the system each year, because that recurring work is what most often gets neglected.
Does the Zabbix AGPL-3.0 license affect how we use it?
Zabbix moved to the GNU Affero General Public License version 3 starting with Zabbix 7.0, while versions up to 6.4 remain under GPL-2.0. The AGPL includes obligations that apply when a modified version is made available to users over a network, so whether anything applies to you depends on whether you modify Zabbix and how you expose it, including any internal portal or custom integration you build on top. Use the Zabbix license page as your starting point, then have your legal counsel confirm how the license applies to your planned deployment, custom code and any plans to share changes outside the organization. Record that decision before you choose a version.
Which open-source option fits a network-only estate?
For a network-only estate of switches, routers and firewalls, LibreNMS is usually the closest match because it is built around SNMP auto-discovery and documents features such as traffic billing by quota or 95th percentile and collection of STP, OSPF, OSPFv3, BGP, VLAN, ARP and FDB data. Zabbix fits better when the same team must also watch servers, databases and applications, since its agent, template and proxy model covers a wider range. Checkmk is a stronger choice for Windows-heavy estates with agents and automatic host registration. Test each candidate against your ten most important sensors before deciding, and confirm that the device types you rely on are covered.
When is a paid support subscription worth it for open-source monitoring?
A paid support subscription is worth considering when you need guaranteed response times, after-hours cover or vendor-backed fixes that your own staff cannot provide. Zabbix sells technical support in Silver, Gold, Platinum, Enterprise and Global tiers, with response times ranging from 1 day on 8x5 support to 1 hour on Global 24x7 support, according to Zabbix's support page. Checkmk's commercial editions bundle 8x5 support with Pro. Compare those response windows with your own on-call obligations and the cost of an outage, then ask any provider, including DeployOpen for implementation and ongoing retainers, for a written scope that states exactly what is covered.
How DeployOpen moves a team off PRTG Freeware
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source monitoring inside your own infrastructure. For a team outgrowing PRTG Freeware, the work starts with a written scope that decides which platform fits your estate, then moves through build, testing and handover.
How we scope
- Inventory devices, sensors and alert rules to decide between Zabbix, Checkmk Community and LibreNMS for your estate.
- Agree in writing which network, server and application checks must carry over and which can be retired.
- Engagements are fixed-scope, with deliverables and timelines agreed before any work begins.
How we build
- Install the chosen platform in your cloud accounts, data center or air-gapped network, with database and proxy design agreed up front.
- Build discovery rules, templates, notifications and dashboards, then test alert paths against real failure scenarios.
- Confirm licensing and support terms for the chosen platform with the vendor before go-live, and document the decisions taken.
How we hand over
- Deliver runbooks covering installation, backup, upgrades, alert routing and day-to-day administration for your operators.
- Walk your team through the running system and record which PRTG sensors map to which new checks.
- Run PRTG and the new platform in parallel for an agreed period so your team can compare alerts before retiring PRTG.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover platform patching, release upgrades and reviews of new checks as your estate changes.
- Ask any provider which platform release lifecycle they will follow and how they will handle upgrades within it.
