What does Zabbix cost to run when the software is free?
Zabbix carries no license fee, so the running cost sits in four places: infrastructure, database storage, staff time and any optional support subscription. Zabbix states that its open source software has no device limits and no feature gates, so the number of monitored hosts and the feature set do not change the software bill. From version 7.0 onward Zabbix is released under the GNU Affero General Public License version 3, and earlier versions under the GNU General Public License version 2. The licence therefore does not decide the cost. Who operates the platform does, and that is the question to size before comparing against a commercial tool.
Infrastructure and database storage are the recurring costs most teams can measure first. Zabbix server, the database, the web frontend and any proxies need compute, memory and disk, and the database grows with the number of monitored items, the polling intervals you choose and how long history and trends are kept. Check the supported database engines and versions for the release you plan to run in the Zabbix requirements page before you price storage, because the database you pick changes both the licence position and the operating effort. Ask any partner or internal team to show the storage growth assumption behind the estimate, including retention settings, so you can test it against your own item count.
Staff time is usually the largest cost and it has both one-time and recurring parts. The build covers installation, templates, discovery rules, alerting, dashboards and runbooks. After go-live the work continues: patching, template maintenance, capacity reviews and upgrades. Zabbix standard releases arrive every 6 months and are supported for 12 months, while LTS releases arrive every 1.5 years and are supported for 5 years, so the upgrade cadence you choose sets how often that effort recurs. Estimate the hours for each recurring task, the people who carry on-call duty and the skills you do not have in house, then compare that total with the cost of a partner retainer.
A paid Zabbix support subscription is optional and recurring. Zabbix sells technical support in Silver, Gold, Platinum, Enterprise and Global tiers, and the tiers differ mainly in coverage hours and response time, from 8x5 support at the Silver level to 24x7 support at the higher levels. Most teams run Zabbix in house for a simple estate and buy a subscription or an implementation partner only for specific gaps, such as 24x7 coverage, a vendor escalation path or a one-off rollout. When you request a quote, ask what the tier includes, the response targets in writing, how the subscription renews and what is excluded, so the comparison with your own staff cost is like for like.
What a Zabbix cost of ownership study includes
A cost of ownership study turns an open-source Zabbix deployment into a costed model your finance, operations and security leads can review. Each card below is one piece of that work, from the inventory that feeds the model to the decisions the study hands back to you.
Monitored host and site inventory
DeployOpen starts by listing the hosts, network devices, applications and sites that Zabbix will watch, with their locations, owners and the check types each needs. This inventory sets the item count, the number of proxies and the alerting load, so every later figure depends on it. Ask for the inventory as a written artifact you can correct before modeling begins.
Server, database and proxy sizing
The study estimates the footprint of the Zabbix server, the database and any proxies from the inventory, including history and trends retention and the number of sites that need a proxy. Compute and storage are the main recurring infrastructure costs in the model. Confirm which database engine and version your standards allow, since the supported versions in Zabbix 7.4 differ by engine.
Operations staffing estimate
Staff time is usually the largest cost in an open-source monitoring platform, so the study estimates the hours needed to run templates, housekeeping, patching, on-call alert tuning and user administration. The estimate states its assumptions about who performs each task, whether that is an internal team, a partner or a mix. Check that the assumed skills and coverage hours match what your team can actually provide.
LTS line and support window review
The study reviews which Zabbix LTS line you would run and how long it receives full and limited support, using the dates published in the Zabbix life cycle policy. An upgrade within the support window carries a different cost than one forced by end of support. Confirm the current dates with Zabbix before you commit, because the release calendar changes.
Support tier comparison against internal coverage
DeployOpen compares the Zabbix paid support tiers, from Silver with 8x5 coverage to Global with 24x7 coverage and a 1 hour response, against the coverage your own team can sustain. The comparison shows where internal staff would be on call and where a vendor subscription would fill a gap. Ask Zabbix for current tier pricing and terms, since the study does not set them.
Cost model, schedule and decision note
The deliverables are a cost model with its assumptions listed, a recurring cost schedule showing which items repeat each year, and a support decision note that recommends an option and states its risks. An open questions list records anything the inventory or your environment did not settle. This study does not include the build, so implementation is priced separately from the written scope.
Which factors move the Zabbix cost of ownership up or down
This table lists the factors that most change what a self-hosted Zabbix deployment costs over its life, with the reason each one matters and a practical way to keep it under control. Read it as a checklist: the driver shows up in your infrastructure and staff time, and the control is something your team or a partner can set during design. Because the software itself carries no license fee, most of the spend follows from these choices.
| Driver | Why it changes cost | How to keep it down |
|---|---|---|
| Monitored hosts and items | Every host, item and trigger adds database writes, storage and server processing, so cost grows with the size of the estate and the polling intervals chosen. | Use standard templates, poll only what someone acts on, and review intervals for low-value items before scaling hardware. |
| Sites and network segments | Remote or segmented networks need proxies, each with its own host, patching and connectivity to watch, which adds moving parts. | Place proxies by site or security zone rather than by individual host, and use proxy groups where the design calls for them. |
| Database choice and data retention | History and trends tables are the largest storage consumers, so retention periods and the database engine set both disk and administration effort. | Set history and trends retention per item type, enable housekeeping, and confirm engine versions against the Zabbix requirements before selecting one. |
| Custom templates and integrations | Each custom template, low-level discovery rule, user parameter, webhook or media type needs building, testing and upkeep through every upgrade. | Reuse vendor-supplied templates where they fit, document each custom component, and limit integrations to documented alerting routes. |
| High availability requirements | A native HA cluster needs extra server nodes, a shared database that is itself highly available, and testing of failover behavior. | Decide the required failover outcome first, then add nodes only for services where a monitoring gap is unacceptable. |
| Number of environments | Development, test, staging and production each carry their own servers, databases, configuration and change control. | Keep non-production environments small, deploy configuration as code, and promote templates through the same path as production. |
| Compliance evidence needs | Access records, audit logs, retention settings, backup tests and change records must be produced and kept for assessors, which adds recurring effort. | Agree the evidence list at scoping, automate exports where possible, and confirm with your auditor which artifacts they expect. |
| Whether support is bought | Paid Zabbix technical support adds a recurring subscription with a response time tier, while staff time to resolve incidents is a separate cost. | Compare the tier's response times against your own on-call coverage, and buy a tier only for the systems where vendor escalation matters. |
How a cost of ownership model is built step by step
The sequence turns an unscoped idea of running Zabbix into a costed model with stated assumptions, so the team can compare self-run operation with a support subscription or a partner engagement. Each phase produces an artifact that feeds the next one.
Discover the current monitoring estate
The work starts by listing what is monitored today, which tools run it, who receives alerts, and which teams own each piece. Your team provides access to existing tools and owners, and the partner documents gaps such as unmonitored sites or manual checks. The step is done when the estate map is agreed and every tool that would be retired or kept is named.
Inventory and size hosts, items and sites
Counts of hosts, monitored items, network sites and expected growth are gathered from the discovery map and sampled from live systems. These numbers set the load the server, proxies and database must carry. The output is a sizing sheet with each assumption marked as measured or estimated, and it is signed off by the owner of the estate.
Select the LTS version and its support window
The team compares the Zabbix long-term support lines against your change calendar and risk appetite. Zabbix publishes full and limited support end dates for each line, so the model records when each option moves out of full support and when it leaves limited support. The output is a chosen LTS line with a dated support window and a note on the upgrade path that follows.
Design the infrastructure and database footprint
Using the sizing sheet, the team designs server nodes, proxies for remote sites, database engine and storage, backup targets and monitoring of the platform itself. The output is a footprint list with compute, storage and network items, each tied to the cloud account, data center or air-gapped environment you already run. Cost lines for these resources come from your own price agreements, so the model keeps them as separate inputs.
Model staffing and the operating model
The team estimates the operating work the platform creates: patching, upgrades, template maintenance, alert tuning, on-call coverage and capacity reviews. It separates one-time build effort from recurring operating effort and shows which roles carry each part. The output is a staffing table with the internal roles, the share of time assumed, and the points where a partner would take over work.
Decide the support tier
The team compares the Zabbix support tiers against the hours and response times your operations need, and against the cost of an outage in monitoring coverage. Tiers differ in coverage hours and response time, so the decision depends on whether your on-call model needs 24x7 cover. The output is a recommended tier, or a decision to run without a paid subscription, with the reasoning written down.
Produce the final model with assumptions and sensitivities
The inputs are combined into a model that shows one-time and recurring costs by category, who is paid for each, and what changes when key assumptions move, such as host count, retention or staffing. Sensitivities show the cases that matter most to the decision. The step is complete when the model, its assumption register and a list of items to confirm in quotes are reviewed with your finance and platform leads.
When a Zabbix support subscription or partner makes sense
A Zabbix support subscription makes sense when your team can run Zabbix day to day but lacks specialist depth for a few high-risk tasks or cannot cover every hour of the day. It does not replace internal operators. Most teams should keep routine work in-house: template upkeep, alert tuning and routine host onboarding. These tasks depend on knowing your estate, your naming conventions and your on-call expectations, and they happen often enough that outsourcing them adds cost without adding much judgment. The skills needed are practical: maintaining item and trigger logic in templates, reading the item and trigger configuration in the frontend, managing host groups and tags, and understanding how alerts reach people.
Other parts of the work are often bought in because they are infrequent, design-heavy or time-sensitive. Initial sizing needs a clear view of the number of monitored items, retention targets and database growth, which draws on capacity planning and database administration skills. Complex high availability design needs experience with the shared database, the failover delay settings and the behavior of standby nodes. Proxy topology across many sites needs network knowledge about segmentation and firewall rules. Upgrade planning needs a tested order for server, proxies and agents, and incident response outside business hours needs an engineer who can diagnose a stalled server or database without guidance.
Zabbix support tiers differ mainly in coverage hours and response time. Silver provides 8x5 support with a 1 day response. Gold provides 8x5 support with a 4 hour response. Platinum, Enterprise and Global provide 24x7 support with 2 hour, 1.5 hour and 1 hour responses respectively. Before choosing a tier, map your last year of monitoring incidents to the hours they occurred and confirm with Zabbix how response time is defined, whether it refers to the first reply or to a fix, and which upgrade or version coverage is included. An 8x5 tier fits a monitoring service that a business-hours team can pause overnight. A 24x7 tier fits a service whose outage would affect customers or regulated operations.
A Zabbix support subscription is a vendor support contract. It gives you access to Zabbix engineers for product questions and defects, but it does not operate your monitoring, write your templates or make decisions about your alerting. Budget it as a recurring annual cost alongside infrastructure and staff time, and confirm the current price and renewal terms directly with Zabbix, because this guide does not state them. Ask whether the subscription covers the specific versions you run, including the LTS line you plan to use, and whether it applies to your proxies and agents as well as the server.
DeployOpen is not a Zabbix partner, reseller or certified provider. Its Zabbix work covers planning, implementation, customization, hardening, backup and upgrades inside your own infrastructure, delivered under a written, fixed scope. If you need an implementation partner for a bounded task such as sizing, high availability or an upgrade, request a written scope that lists deliverables, handover steps and the operator skills your team must have at the end. A partner should leave your team able to run Zabbix, not dependent on it.
Recurring costs after go-live: what to budget each year
This table lists the recurring costs of running Zabbix after go-live, who pays for each, what pushes it up and what to request in a quote. Zabbix has no license fee, so the annual budget is mostly infrastructure, staff time and any support contract. Read each row as an annual line item, and check the release dates before you set the upgrade budget.
| Cost component | Who pays | What drives it up | What to request in a quote |
|---|---|---|---|
| Server and proxy hosting | Your infrastructure team or cloud account | Host and item count, polling intervals, number of proxies and HA server nodes | Compute, storage and network sizing per node, based on your item count and retention |
| Database storage and backups | Your infrastructure team, through cloud or hardware costs | History and trend retention, item count, backup frequency and restore testing | Storage growth estimate, retention settings, backup schedule and restore test plan |
| Monitoring of the monitoring | Your operations or platform team | Number of server nodes, proxies and databases that must alert when they fail | Internal alerts for server, proxy and database health, with a named owner |
| Staff time for template and alert upkeep | Your monitoring team, or a partner retainer | New applications, changed hosts, alert tuning and noise reduction | Estimated hours per month, template ownership and a review cadence |
| Upgrades (recurring labour) | Your team or a partner under a fixed-scope engagement | Each upgrade cycle carries labour, plus schema changes and template rework | Scope per version step, test environment, rollback plan and post-upgrade checks |
| Upgrade timing | Your team or a partner, per upgrade cycle | Lines end: 6.0 LTS limited support ends 28 February 2027; 7.0 LTS full support to 30 June 2027 | Upgrade plan for 8.0 LTS (planned Q4 2026, full support to Q4 2029) |
| Support subscription or partner retainer | Zabbix for a subscription, or a partner for a retainer | Required response time, hours of cover, number of sites and escalation needs | Tier name, hours of cover, response times, exclusions and renewal terms |
| Internal skills development | Your organization | Staff turnover, new release features, and new database engine versions | Training plan, documentation owner and cross-training for on-call staff |
Where Zabbix cost estimates usually go wrong
Zabbix estimates tend to miss the same few items: data volume, network reach, version lifetime, operator coverage, upgrade work and the role of paid support. Each card names one risk and the check that prevents it. Address them before the budget is approved, because open-source Zabbix has no license fee and the recurring costs otherwise stay hidden.
Underestimated item counts and history growth
Estimates often start from the number of hosts and skip the number of items each host carries, including items created by low-level discovery. Item count and update interval set how many values reach the database each hour, and history retention decides how long each value stays. Build the estimate from an item inventory exported from the current tool or from a sample of pilot hosts, and set history and trends retention before go-live so the database sizing and housekeeping settings match.
Proxies and network segmentation omitted
Monitoring across separate networks, remote sites or DMZ zones usually needs proxies, each with its own host, storage and firewall rules. Estimates that assume one server can reach every host understate the number of proxies, the firewall change requests and the time needed to approve them. List the network zones and sites that need collection, cost proxies per segment, and from Zabbix 7.0 decide whether proxy groups are needed for load balancing and failover.
Support end date on the chosen version
A budget built for a version that leaves full support soon will likely need an upgrade within the first years of operation. Zabbix 7.0 LTS has full support until 30 June 2027 and limited support until 30 June 2029, while Zabbix 6.0 LTS limited support ends on 28 February 2027. Check these dates in the life cycle and release policy against the planned go-live, and confirm with Zabbix whether the newer LTS line planned for Q4 2026 fits your timeline.
One operator assumed for all monitoring
Staff time is often costed as a fraction of one engineer's week, which assumes that person is available for alert triage, template maintenance, host onboarding and incident work. Monitoring that alerts outside office hours or covers several teams needs a named primary operator, a named backup and a documented rota. Write the rota into the estimate as recurring hours, and confirm that the backup has the same frontend and database access as the primary.
Upgrade effort left out of the budget
Each LTS line brings new versions of the server, frontend, database schema and agents, and standard releases arrive every six months with 12 months of support. Estimates that cover only the first installation leave out test environments, database schema upgrades, agent rollout and template review. Ask for upgrade effort as a recurring line item, and plan the order for server, proxies and agents with a rollback point for each step.
Support subscription mistaken for staff
A paid support subscription gives access to Zabbix technical support at a stated response time, from 8x5 support with a 1 day response (Silver) to 24x7 support with a 1 hour response (Global). It does not run monitoring, maintain templates, tune housekeeping or respond to alerts for your team. Compare each tier's response time with the operator coverage you already have, and keep the internal operator cost and the subscription as separate budget lines.
How the cost picture changes by starting point
Teams leaving a commercial monitoring product usually pay for licenses, maintenance and vendor support today, so the comparison starts with which of those costs actually end. Zabbix open source has no license fee and no device limits, but the labor to rebuild templates, triggers, alerts and dashboards, and the time spent running both systems in parallel, become the main cost drivers.
- Licensing exit: confirm the current contract end date and any notice period, because parallel running extends the overlap period.
- Staffing: existing administrators know the old tool well, so plan time to learn Zabbix items, triggers and templates.
- Infrastructure: database and proxy sizing is new work, and history stored in the old tool usually stays there unless you migrate it.
- Support: decide whether internal skills or a Zabbix support tier will cover production incidents during the first months.
Before deciding how long the old system must stay online, confirm with its vendor which export formats and data retention options are available.
Teams running Zabbix 6.0 face a dated decision. According to the Zabbix life cycle and release policy, 6.0 LTS limited support ends on 28 February 2027. The cost picture changes because routine operation becomes a planned version change, with testing, database schema upgrade work and coordination across server, proxies and agents.
- Deadline: plan the upgrade window against the 28 February 2027 end of limited support for 6.0 LTS.
- Target line: Zabbix 7.0 LTS has full support until 30 June 2027 and limited support until 30 June 2029, while 7.4 has full support until Zabbix 8.0 LTS. Choose the target that matches your roadmap.
- Staffing: assign an owner to review custom templates, webhooks and media types, since changes between versions can affect items and alerts.
- Support: check whether a support subscription covers upgrade questions and at which tier, because the scope differs by tier.
Ask your team to list every custom component in use, then confirm with Zabbix which of them the target version supports without change.
Running Zabbix on Kubernetes or another container platform moves cost from dedicated servers to shared cluster capacity, storage classes and platform team time. The server, frontend and proxies can run as containers, but the database, persistent storage and high availability design still need explicit decisions, and they usually shape the budget more than the containers do.
- Infrastructure: cluster nodes are shared, so the database and history storage need dedicated volumes and performance planning.
- High availability: the native server cluster and proxy groups from Zabbix 7.0 onward depend on how nodes and the database are scheduled, so test failover in your own cluster.
- Staffing: platform engineers often run the container layer while monitoring administrators own Zabbix configuration, which splits on-call responsibility.
- Support: confirm whether the support scope covers containerized deployments and which image source and versions it accepts.
Before sizing, confirm with your platform team which storage classes and database versions your chosen image supports. Zabbix 7.4 lists supported MySQL, MariaDB, PostgreSQL and TimescaleDB versions, so check those against your image.
In air-gapped or tightly restricted networks, the cost picture depends on how packages, updates and support access reach the environment. Zabbix open source has no license key to activate, but installation, updates and troubleshooting still depend on sourcing packages through an approved channel and on a support path that needs advance planning.
- Package sourcing: define how packages, container images and templates enter the network, and how they are verified, because each release adds staff time.
- Update cadence: standard releases arrive every 6 months and LTS releases every 1.5 years, so the import process repeats on that schedule.
- Support access: remote support sessions may be restricted, so confirm with Zabbix which access methods the chosen tier allows.
- Staffing: keep more than one trained person able to rebuild the system from approved sources without internet access.
Confirm with Zabbix and your security team what can cross the boundary, and document that path before you estimate staff time for updates.
What you need to provide for an accurate cost model
The cost model is only as accurate as the inventory behind it, so collect four things before any number is discussed. First, an export or list of monitored hosts, with the items and triggers attached to each one and the templates currently linked. Item and trigger counts drive database growth and server load, so a host list without them cannot support a sizing estimate. Second, a map of sites and network zones showing where each host sits, which links cross firewalls, and which locations have no direct path to a central server. That map determines how many proxies are needed and where they should run.
Third, document the current monitoring estate and its costs. List every tool in use, including Nagios, PRTG or any other product, with licence fees, support contracts, hosting costs and the hours staff spend maintaining checks and alerts. Zabbix removes the server licence fee, but it does not remove staff time, so the baseline you compare against should reflect the full cost of the current setup. Fourth, record retention and compliance requirements: how long history, trends and event data must be kept, and whether any regulator, internal policy or contract sets those periods. Retention is one of the largest levers on storage cost, so these figures must be written down, not assumed.
Fifth, name the owner of the monitoring platform and the operators who will run it, with their working hours and any on-call duties. Cost follows coverage. A team that can respond during business hours has different staffing needs from one that must answer alerts overnight, and that difference also determines whether a support tier is worth buying. Sixth, arrange access to the current environment or, if that is not possible, to a representative sample of hosts and configuration exports from two or three typical sites. Access lets the team confirm assumptions instead of guessing from a spreadsheet.
Four decisions are needed before the model can be finalized. Choose the target LTS line: Zabbix 7.0 LTS has full support until 30 June 2027 and limited support until 30 June 2029, while Zabbix 8.0 LTS is planned for Q4 2026, so confirm its release status at the time you request a quote. Decide whether a Zabbix support subscription is required and, if so, which tier, since response times and coverage hours differ across the published tiers. Decide whether the high availability requirement applies, because a second server node and a shared database add infrastructure and operating effort. Finally, agree the approval path with finance and procurement, including who signs off, how many years the model covers and whether recurring costs need separate approval.
Questions buyers ask before paying for Zabbix cost help
Does Zabbix charge a license fee for its software?
No. 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, optional purchase. The license changed in version 7.0: from 7.0 onward Zabbix is released under the GNU Affero General Public License version 3, while all versions up to 6.4 were released under the GNU General Public License version 2. The AGPL matters most if you modify Zabbix and make the modified version available to users over a network. Have your legal or compliance team confirm what the license requires for your specific use.
What are the real running costs of a Zabbix deployment?
The recurring costs are infrastructure, database storage and staff time. Main drivers:
- Number of monitored items and how often they are polled
- History and trends retention, which sets how fast the database grows
- Number of proxies and remote sites, each with its own hosts to run
- High availability design, including extra server nodes and a shared database
- Backup, restore testing and disaster recovery storage
- Time spent maintaining templates, alert routes, dashboards and upgrades
Staff time is usually the largest cost and the easiest to underestimate. Ask for each cost line separately in any quote so you can change one assumption without rebuilding the whole model.
How long does a Zabbix cost model take to produce?
The duration is set in the written scope, which is agreed before any work starts. The main factors are the number of sites, the number of hosts and items, whether you already have a current inventory, how many data sources feed the model, and how many stakeholders must review the assumptions. A model for a single site with an existing inventory takes less time than one covering many remote sites, several databases and a high availability design. Ask for the duration, the review points and the deliverable format in the written scope.
Can our own team build a Zabbix cost model without outside help?
Yes, if one person owns the inputs and the team can pull the data. Your team needs the current host and item counts, polling intervals, the retention you require, the number of sites, the planned database and the hours that operators, on-call staff and template maintainers spend today. Zabbix documentation on housekeeping and database sizing explains how retention and item volume affect storage. Outside help is most useful for checking assumptions, testing the model against a realistic load and challenging the staffing estimate, which teams often leave out.
Does a Zabbix support subscription replace internal monitoring staff?
No. A support subscription gives you vendor technical support with defined response times. It does not operate your monitoring, write or maintain your templates, respond to your alerts at night or run your upgrades inside your environment. Your team still owns daily operations, change control and incident response. Treat the subscription as a way to get faster answers to hard technical problems, and budget internal time separately. Confirm the exact scope of support in the subscription terms before you buy.
Which Zabbix support tier fits a 24x7 requirement?
Platinum, Enterprise and Global are the tiers that provide 24x7 support, with response targets of 2 hours, 1.5 hours and 1 hour respectively. Silver provides 8x5 support with a 1 day response target. Gold has a 4 hour response target, so confirm its coverage hours with Zabbix before you assume round-the-clock cover. Choose by the response time your incident process needs and by whether your critical systems must be covered outside business hours. Get the coverage hours, severity definitions and response targets in writing from Zabbix.
What does our team need to provide for a cost review?
Prepare these inputs before the review starts so the scope can be fixed quickly:
- A current inventory of monitored hosts, items and triggers
- Sites, network segments and proxy requirements
- Retention targets for history, trends and events
- The hosting platform for the server, database and proxies
- Your high availability and backup requirements
- Staffing and on-call model for monitoring
- Read-only access to an existing Zabbix or monitoring tool, if one is in place
- A named decision-maker who approves assumptions and the written scope
Missing inputs usually become extra assumptions, which makes the final cost model less reliable.
How DeployOpen scopes, delivers and hands over Zabbix cost work
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including Zabbix. For cost of ownership work, we model the running costs you will carry and the support options you could buy, then deliver that model as a written, fixed-scope engagement you can compare against your own team's estimate.
How we scope
- Written scope names the Zabbix version line, server and proxy count, database engine and monitored host estimate it covers.
- Cost model separates infrastructure, database storage, staff time and any support subscription so each line can be challenged.
- Quote lists which items are one-time, such as design and migration, and which recur, such as hosting, storage growth and upkeep.
How we build
- Sizing assumptions for history and trends retention are tested against a sample of your monitored items before the model is finalized.
- Support tier comparison is set against your required response hours and your own in-house capacity, using Zabbix's published tiers.
- Each assumption is recorded with its source, so finance and platform teams can rerun the model after a version or retention change.
How we hand over
- You receive the cost model as a spreadsheet, with the inputs, formulas and assumptions documented for your team to maintain.
- A written summary sets out which decisions are open, such as LTS line choice or whether to buy a subscription, and who owns each one.
- Runbooks cover the recurring tasks the model depends on, including database housekeeping, capacity reviews and version lifecycle tracking.
How we support
- Ongoing support, upgrades and continuous review of the cost model are available as a retainer, scoped separately from the initial engagement.
- Lifecycle dates from Zabbix's release policy are reviewed on a schedule so the model reflects current full and limited support end dates.
- Confirm with Zabbix and your own environment any figure that changes between releases before relying on it in a budget.

