How Zabbix dashboards in Grafana connect to your monitoring data
The supported route is the Grafana Labs Zabbix plugin reading the Zabbix API, and the work for a team that already runs Zabbix is data source setup, access design and panel design. Zabbix stays the system of record for hosts, items, triggers and problems. The plugin sends queries to the Zabbix API and draws the answers in Grafana panels, so a renamed host, a retuned trigger or an acknowledged problem changes in Zabbix first and appears in Grafana on the next query. Grafana holds no separate copy of the monitoring model, which means there is one place to fix host and trigger definitions.
Data source setup is the first decision. The Grafana data source needs the Zabbix API endpoint, an authentication method and whichever cache and timeout options the plugin version exposes. Traffic runs from the Grafana server to Zabbix, so confirm that network path, and point the endpoint at a stable address if your Zabbix frontend sits behind a load balancer or a failover pair. Every panel query is an API call, so a dashboard with many panels and long time ranges adds load to the Zabbix server and database. Ask the team that operates Zabbix to review expected query volume before the first wide rollout.
Access design decides what each viewer can see. The plugin acts with the Zabbix identity configured in the data source, so Zabbix user group and host group permissions limit the hosts, items and problems that any dashboard can show, whatever Grafana role the viewer holds. Grafana roles then control who can view, edit and administer dashboards. A single shared Zabbix account with broad read access means every Grafana viewer sees everything that account can read. Decide the identity model before building dashboards, because changing it later means revisiting every panel. Test each audience's view with a user that has the same Zabbix permissions they will have in production.
Panel design for problem views should use Zabbix's own severity, status and recovery data instead of re-deriving them in Grafana. Keep acknowledgment, maintenance and tuning actions in Zabbix, so operators act in one place. Before publishing, confirm the plugin version matches both your Zabbix version and your Grafana version. The plugin is a Grafana Labs project, so check its release notes and compatibility information directly, and test a known trigger on a staging host to confirm that a problem appears, clears and is labeled correctly.
What you need in place before connecting Grafana to Zabbix
Connecting Grafana to Zabbix touches four parts: the Zabbix server and its database, the Grafana server and its own database, and the access and network path between them. Each card below is a prerequisite to settle before you create the data source. Decide versions and editions first, then the databases, then the account and network path, and check each one against your own environment and the vendor policies.
Zabbix version and life cycle
Pick the Zabbix line first, since it sets the API and server behavior your dashboards depend on. Zabbix 7.4 was released on 1 July 2025 and has full support until Zabbix 8.0 LTS, then limited support until Q1 2027. Zabbix 7.0 LTS has full support until 30 June 2027 and limited support until 30 June 2029. Confirm these life cycle dates against the vendor policy before you commit, because support windows can change.
Supported Zabbix database
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. Confirm that the database version you run sits inside one of these ranges and that your backup and restore process covers it. Dashboards that load long history ranges depend on how this database is sized and how long history is retained. SQLite is available for Zabbix proxies only, so it does not apply to the server.
Grafana release line and edition
Use a Grafana release from the current 13.x line, such as 13.2.0, released on August 18, 2026, and apply its patch releases. Grafana's upgrade guidance states that each minor release is supported for 9 months and the last minor release of a major version for 15 months, so plan a regular upgrade rhythm. Choose the edition before you build, because SAML, team sync, active sync and SCIM are available only in Grafana Enterprise and Grafana Cloud. Confirm that the Zabbix plugin version you need supports your Grafana version.
Grafana configuration database
Grafana stores its configuration in SQLite by default, but the installation documentation states that SQLite does not scale for production. Provide MySQL 8.0 or later, or PostgreSQL 12 or later, as a dedicated database for Grafana itself, separate from the Zabbix database. This database holds dashboards, data source settings and users. If you plan two or more Grafana servers behind a load balancer, the shared database is required, and alerting needs extra configuration to avoid duplicate notifications.
Zabbix API account and access scope
Create a dedicated Zabbix user for Grafana with read access only to the host groups in scope. Dashboards show whatever this account can see, so a broad role exposes every host to every Grafana viewer. Confirm the user type and role assignments in your Zabbix version. Decide whether each Grafana user needs a personal Zabbix API token or whether a shared service account is acceptable under your access policy, and record the account owner and rotation process.
Network paths and TLS certificates
Open a path from the Grafana servers to the Zabbix web API, and confirm that firewall rules, proxies and DNS resolve the Zabbix frontend name from Grafana's network segment. Issue TLS certificates for both services, with names that match the URLs Grafana uses and a trust chain that the Grafana host accepts. A certificate that expires or does not match the configured URL is a likely cause of a broken data source, so track renewal dates for both services.
How to set up the Zabbix data source in Grafana, step by step
This sequence connects Grafana to Zabbix through a dedicated, least-privilege API identity and checks each layer before dashboards depend on it. Each step ends with a repeatable check, so a failure can be traced to one component.
Install the Zabbix plugin and confirm it loads
The Grafana administrator installs the Zabbix data source plugin on the Grafana server, using the method that matches the deployment: operating system package, container image or provisioning. After a restart, check that the plugin appears in the list of installed data source types and that the Grafana server log shows no signature, loading or version errors. Record the Grafana version and the plugin version together, because you will need both when you plan upgrades. The step closes when the plugin is listed as installed and loads cleanly.
Create a dedicated Zabbix API user
A Zabbix administrator creates a user account that only Grafana uses, with its own name and no shared login. Assign it to a user group and a role that grants read access to the host groups chosen for dashboards and denies configuration changes. Choose an authentication method your identity team can audit, and confirm with the Zabbix documentation for your version which token or password option is supported. The step closes when a login with this account shows only the expected host groups in the Zabbix interface.
Add the Zabbix data source with API access
In Grafana, add a new Zabbix data source and enter the API endpoint of your Zabbix web frontend, using the path documented for your Zabbix version. Enter the credentials created for Grafana, and store any token or password in Grafana's secure fields so it stays out of dashboard JSON. If you provision the data source from files, pass secrets through environment variables or your secret store. The step closes when the data source saves without validation errors.
Test the connection before building panels
Run the data source test and read each line of the result. A passing test confirms that the Grafana server can reach the Zabbix API, that the login succeeds and that the API version check completes. If it fails, check name resolution, certificate trust for internal certificate authorities, and any proxy or firewall between the two servers. Then open the host group selector and confirm that it lists only the groups granted to the dedicated user. The step closes when the test passes and the group list matches the role from the previous step.
Build a history panel on a test group
Choose a non-production host group that contains a lab host you know well, ideally one whose load you can generate on demand. Create one time series panel that queries a single numeric item, and set the host group, host and item filters explicitly so that no wildcard matches other hosts. Compare the latest values with the Latest data view in Zabbix for the same host and item, checking the timestamps and units. The step closes when the panel returns values that match the Zabbix view for the known host.
Build a problems panel and compare it with Zabbix
Add a problem list panel that uses the same host group filter, and set the severity and tag filters to match a view your team already uses in Zabbix. Open the Problems view in Zabbix with identical filters and compare each row: problem name, host, severity, start time and acknowledgement status. Trigger a problem on the lab host, then confirm that it appears in both views and disappears from the Grafana panel after recovery and a refresh. The step closes when both lists show the same problems for the same filter.
Add a host availability panel and verify it
Create a panel that shows the availability state of hosts in the test group, using the availability information the Zabbix plugin exposes in your version. Confirm which availability fields are available before you design the panel, because agent, SNMP, JMX and IPMI interfaces may report separately. Stop the agent on the lab host for a short period you control, and confirm that the panel changes state and matches the host availability shown in Zabbix. Restart the agent and confirm the panel recovers. The step closes when both state changes match in Grafana and Zabbix.
Widen the scope to production host groups
After all three panel types match Zabbix on the test group, extend the dedicated role to the production host groups that the dashboards need, and no others. Repeat the same comparisons for one production group at a time, starting with the group that carries the least operational risk, and review the query load that dashboards place on the Zabbix database before adding the next group. Record each group added, the reviewer and the date in your change record. The step closes when each production group passes the same comparison as the test group.
How Zabbix objects map to Grafana filters, roles and panels
This table compares each Zabbix object with its Grafana counterpart, including data source variables, filters, folders, teams and panels. Read each row for the owner and the place where the mapping changes, because Zabbix and Grafana permissions are separate layers that must be aligned by design. The main takeaway is that identity mapping depends on your Grafana edition, so confirm SAML and team sync availability before you plan group-based access.
| Zabbix object | Grafana counterpart | Who owns the mapping and where it changes |
|---|---|---|
| Host groups | Group variable in the Zabbix data source query | Zabbix admins manage group membership in Zabbix; dashboard authors set the variable in Grafana |
| Hosts | Host variable chained to the group variable | Zabbix admins add or remove hosts; changes appear after the variable refreshes |
| Items and tags | Item and tag filters in panel queries and tag variables | Template authors set tags in Zabbix; dashboard authors choose items and tags in Grafana panels |
| Problem severities | Minimum severity filter on problem panels | Zabbix admins set severity on triggers in templates; dashboard authors set panel filters |
| User groups and roles | Grafana teams and roles, assigned separately from Zabbix permissions | Zabbix admins control Zabbix access; Grafana admins control Grafana access. Align both by design. |
| Identity mapping from SAML or LDAP | LDAP in all editions; SAML and team sync in Enterprise and Cloud only | Identity team manages groups in the identity provider; confirm your Grafana edition before designing group mapping |
| Dashboard folders | Folders per team or domain with folder-level permissions | Grafana admins create folders and permissions; provisioning files can also define folders and dashboards |
When to keep dashboards in Zabbix instead of Grafana
Decide per audience before you build a single panel. The question is not whether Zabbix or Grafana is the better tool, but which people will look at which views, and whether a second system adds value for them or only adds another login, another permission model and another thing to upgrade. Zabbix dashboards, maps and the problems view are the right home for operators who already work in the Zabbix frontend, because the problem list, acknowledgment workflow, event tags and host context are all there without any translation layer.
Keep alert-centric views in Zabbix when the work starts from a trigger. An operator who needs to see the active problem, its severity, who acknowledged it, what has been done and whether it has been suppressed through maintenance is served best by the Zabbix problems widget and the event detail page. Rebuilding that workflow in a second tool means your team maintains two sources of truth for acknowledgments and recovery state. Maps also belong in Zabbix when they show host status and the link between hosts, since they update from the same problem data that drives notifications.
Grafana earns its place when a view must combine Zabbix with data it cannot hold. Logs from a log platform, traces, cloud billing data or business metrics can sit beside Zabbix series on one time axis, which is hard to do well inside the Zabbix frontend. Wall displays for a network operations center or executive summaries are another common case, because they need a kiosk-style layout, rotation and read-only access for people who should never see the configuration. Dashboards maintained as code, using Grafana provisioning files or a Terraform workflow, also favor Grafana when your change process requires reviewed, versioned dashboard definitions.
Many teams run both, and that is a sound design when each audience has a clear home. A typical split keeps on-call operators in Zabbix for problems and acknowledgments, while service owners and management get Grafana views built from the same Zabbix data. Before you build, list each audience, the questions they ask during an incident and during a normal week, and whether they need write actions such as acknowledging a problem. Confirm with your own team whether the people who need read-only access also need Zabbix accounts, since that choice drives the role and user group design for both systems.
How to secure the Zabbix to Grafana connection
Grafana connects to Zabbix through an API account and a data source definition, so the security of the connection depends on both products and the files that configure them. The cards cover Zabbix account design, user access in both products, Grafana's hardening settings and how provisioning keeps secrets out of version control. Confirm which hardening settings apply to your chosen Grafana version before you change production.
Zabbix API account scope and rotation
Grafana reaches Zabbix through the Zabbix API, so the account behind the data source defines what every dashboard viewer can read. Create a dedicated Zabbix user with read access only to the host groups the dashboards need, and avoid granting a Super Admin role. Set a rotation schedule for its password or API token, and confirm with your Zabbix version how tokens are issued, expired and revoked. Test rotation on a staging copy before the production data source is changed.
No shared logins between users
A shared Zabbix or Grafana login hides who viewed or changed what, and it slows offboarding because every user depends on one credential. Give each person a named account in both systems and use per-user tokens for API access where your plugin version supports them. Review the audit trail for generic accounts such as admin or monitoring, and retire any that dashboards still depend on. Confirm with the plugin documentation which authentication options your chosen version offers.
Per-user access through groups and roles
Access should be designed in two layers. In Zabbix, user groups and host group permissions decide which hosts and problems a user can see at all. In Grafana, roles decide who can view, edit or administer dashboards and data sources. Map each Grafana role to a Zabbix group that gives matching visibility, so a viewer cannot see through Grafana data that Zabbix would hide. Document the mapping and check it by signing in as a test user in each role.
Browser-facing hardening settings
Grafana's security hardening guidance recommends secure and SameSite cookies, so session cookies are sent only over HTTPS and are restricted on cross-site requests. It also covers a Content Security Policy to limit which scripts and resources the browser loads, and Trusted Types to reduce DOM-based script injection. Enable these in the server configuration, then test every dashboard, panel and plugin you use, because a strict policy can break panels that load external resources. Confirm each setting against your Grafana version before rollout.
Server-facing exposure controls
Three settings reduce what an outside party can learn or reach from Grafana. Hiding the Grafana version from unauthenticated users prevents version-specific probing. Requiring authentication for the metrics endpoint keeps internal counters away from anyone who can reach the port. Domain verification guards against DNS rebinding, where a hostile site uses DNS to reach an internal Grafana through a visitor's browser. Test these behind your load balancer and reverse proxy, since they can change which address Grafana sees.
Provisioning files and version control
Grafana provisioning files define data sources, dashboards and alerting resources at startup, so the Zabbix data source definition lives in a file that teams review and copy. Keep the Zabbix API token and any passwords out of that file and out of Git history. Reference secrets through environment variables or a secrets store your organization already runs, and scan commits for accidental credentials before they reach a shared repository. Ask your implementation partner which provisioning and secret handling pattern fits your Git and deployment workflow.
How to test Zabbix Grafana dashboards before users rely on them
Before any team relies on a Zabbix and Grafana dashboard, confirm that a restricted user sees only the host groups granted to them, and confirm it in both systems. Zabbix enforces host group access through user groups and user roles, while Grafana applies its own folder and dashboard permissions on top of the data source. Create a test user in Zabbix whose user group has read access to one host group only. Then sign in to Grafana as that user, or use the credentials or token the data source uses for that user. Open every dashboard and every panel, including the host and item selectors. Any host, item or problem from outside the granted group is a failed test, and the fix belongs in the permission model, so hiding panels is not an acceptable fix.
Next, compare panel values with the Zabbix frontend for a sample of hosts. Pick hosts from different templates and host groups, including at least one host with low-frequency items and one with preprocessed or calculated items. For each sample, compare the latest value, units and time window in Latest data or a graph in Zabbix against the same item in the Grafana panel. Differences usually come from the time range selected in Grafana, aggregation functions such as average or max applied inside the panel, or trend data being shown where history is expected. Record every mismatch and its cause before the dashboard goes live. A panel that differs by a few seconds is easier to explain to operators than one that is quietly wrong for a week.
Problem panels need a controlled test. Agree a maintenance window or use a non-production host, create a simple trigger that you can fire on demand, and confirm that the problem appears in the Grafana problem panel with the expected severity, host name, tags and acknowledgement status. Acknowledge the problem in Zabbix and confirm the state change appears in Grafana. Then let the trigger recover and confirm the panel clears. Test your tag and severity filters with both a matching and a non-matching problem. Time how long the panel takes to show the event, and record the refresh interval set on the dashboard, because a slow refresh can make a working alert look broken to the people watching it.
Test dashboard variables separately, because they return the host and item lists that drive every other panel. Check that each variable returns the hosts the restricted user should see and nothing else, that dependent variables update when a parent value changes, and that empty results show a clear message instead of broken panels. For high availability, the Grafana docs describe two or more active-active servers behind a load balancer, all sharing a MySQL or PostgreSQL database, with database-backed auth tokens so users can reach any node. The same docs state that alerting needs extra configuration to avoid duplicate notifications and that Grafana Live has limitations in HA. Confirm these limits for your chosen Grafana version before relying on live updates or alert routing, then stop one node during an active session and confirm the user can keep working.
Why Zabbix panels in Grafana show no data or the wrong hosts
This table lists the failures that most often leave Zabbix panels in Grafana empty or showing the wrong hosts, with the likely cause and the first check or fix for each. Work through the rows in order, since the data source connection and API user permissions are usually the first things to verify. Many symptoms come from scope, filter and permission settings rather than from broken monitoring data.
| Symptom | Likely cause | Check first or fix |
|---|---|---|
| Data source test fails | The API URL does not point to the Zabbix frontend API endpoint, or Grafana does not trust the certificate chain presented by the Zabbix web server. | Confirm the URL ends in the frontend API path and reaches Grafana's network. For TLS errors, add the internal CA to the Grafana host or container trust store and retest. |
| Panels are empty for a user who can log in | The Zabbix user or the per-user API token has no read permission on the host groups that contain the monitored hosts. | Compare the user's group permissions with the host groups used in the panel query. Grant read access to the groups, then reload the dashboard as that user. |
| Plugin errors or missing fields after an upgrade | The Grafana Zabbix plugin version is not compatible with the Zabbix server or frontend version in use. | Check the plugin's compatibility notes against your Zabbix version before upgrading either side. Upgrade the plugin and Zabbix in a planned order, and test one dashboard afterwards. |
| Dashboard shows only some hosts | A dashboard variable for host group, host or item filters the list to a value that no longer matches, or a regex variable excludes hosts. | Open the variable's current values and query preview. Reset the variable to All or correct the pattern, and check whether the variable is set to include hidden or disabled hosts. |
| Problem panel differs from the Zabbix frontend | Severity thresholds, tag filters, acknowledgement status or the 'show suppressed' option differ between the panel and the frontend view. | Match the panel's severity, tag and acknowledgement settings to the frontend filter used by the operators. Compare the same time window and host scope before changing thresholds. |
| Dashboard loads slowly on long time ranges | Panels query raw history over wide time ranges, so the Zabbix API and database do much more work than a short view needs. | Narrow the default time range and review the plugin's trend and aggregation options for long periods. Use trends for long-range graphs where the data source supports it, and keep raw history for short investigations. |
| Dashboards or users behave inconsistently across Grafana nodes | Grafana runs on SQLite for its configuration database in a multi-node setup, so nodes do not share state. | Check the database type in the Grafana configuration. Move the configuration database to MySQL 8.0 or later, or PostgreSQL 12 or later, before adding nodes behind a load balancer. |
| Duplicate alert notifications in an HA setup | Grafana alerting runs on more than one active node without the HA alerting settings, or Zabbix and Grafana both send notifications for the same condition. | Confirm the Grafana HA alerting configuration is in place, and decide which system owns each alert. Remove duplicate notification rules on one side before tuning the other. |
Questions buyers ask about Zabbix and Grafana dashboards
What drives the cost of a Zabbix and Grafana dashboard project?
The main drivers are the number of host groups and dashboards in scope, how many user groups need different access, whether Grafana signs users in through your identity provider, and whether the Zabbix server runs as a high availability cluster that must be tested under failover. Each adds design, build and verification work. Dashboards are rarely the costly part on their own. The access model and identity work usually take more effort than panel layout. Design and build are one-time costs. Hosting, storage, database operations and any support or Grafana Cloud subscriptions recur. Ask for a written scope that lists each host group, each dashboard with its owner, each identity source, and the high availability and test expectations, so the quote maps to named items.
How long does a Zabbix and Grafana dashboard engagement take?
No duration should be fixed until the written scope is agreed, because length depends on the same factors that drive cost: host groups, dashboards, identity integration and whether high availability is included. A narrow scope with one data source, a small set of dashboards and local accounts is short. A scope with single sign-on, per-user tokens, access rules mapped to Zabbix user groups and a tested high availability pair takes longer. Schedule also depends on how quickly your administrators and identity owners make decisions and on the change windows available for testing. Ask for a timeline organized in phases, the dependencies on your team in each phase, and the acceptance tests that close each phase.
What does our team need to provide before dashboard work starts?
Start with named people. You need Zabbix administrators and Grafana administrators who can make configuration changes and approve them, and identity owners for your directory or single sign-on provider who can create service accounts and group mappings. Provide a test host group with representative hosts so panels and problem views can be checked against real problems before production. Decide dashboard ownership early: who edits shared dashboards, who owns each folder, and which views stay in Zabbix. Also provide network paths from Grafana to the Zabbix API, access to the database hosts for the high availability design, and a change window. When these inputs are late, the build waits, so confirm them in the written scope.
Can an internal team set up Zabbix and Grafana dashboards alone?
Yes, an internal team with production experience in both products can build this alone. Both are open source, and their documentation covers data source setup, tokens and provisioning. The useful question is whether your team has run Zabbix in production, has built a Grafana high availability setup with a shared MySQL or PostgreSQL database, and has time to test failover and access rules. Grafana's documentation states that SQLite does not scale for production, and its high availability setup needs a load balancer and extra alerting configuration to avoid duplicate notifications. Compare the skills in your team against the written scope, then decide which parts to keep in-house and which to hand to a partner, such as high availability testing or identity mapping.
Does Zabbix have a license fee or device limit?
No. Zabbix states that its open source software has no license fee, no device limits and no feature gates. From version 7.0 onward Zabbix is released under the GNU Affero General Public License version 3, and versions up to 6.4 were released under GPL version 2. Paid technical support is a separate subscription with Silver, Gold, Platinum, Enterprise and Global tiers, ranging from 8x5 support with a 1 day response (Silver) to 24x7 support with a 1 hour response (Global). Costs that remain are the infrastructure, database, storage and the people who run the platform. Plan upgrades too. Standard releases are supported for 12 months, and LTS releases carry five years of support, three of full support and two of limited support. Confirm current terms on the Zabbix license and support pages.
What does Grafana cost to license for self-hosted dashboards?
Grafana's cost depends on the edition you choose and on whether you use Grafana Cloud. Since April 20, 2021, Grafana, Loki and Tempo have been licensed under AGPLv3, and Grafana Enterprise is offered as a non-AGPL commercial option. Several authentication methods are limited to Enterprise and Grafana Cloud, including SAML, team sync, active sync and SCIM provisioning. Grafana Cloud has a free tier, a Pro tier with a 19 US dollar monthly platform fee plus usage, and an Enterprise tier with a minimum commitment of 25,000 US dollars per year, according to the Grafana pricing page. Ask for a written licensing position for each edition against the features you need, and confirm the terms for your intended use with Grafana Labs before you commit.
What breaks when Grafana connects to Zabbix in production?
The most common failure is a token tied to one administrator account. When that account is disabled or its token expires, panels go blank. The second is a permission mismatch: Zabbix user groups and Grafana roles that do not match can expose host groups to people who should not see them. In high availability setups, Grafana needs a shared database and a load balancer, and alerting needs configuration to prevent duplicate notifications. Grafana Live also has limitations in high availability, so test live views on each node. Before handover, check access by signing in as a restricted user, confirm that each panel returns data on the test host group, and stop one Grafana node to confirm that users can still reach dashboards.
Should dashboards live in Zabbix or Grafana?
Keep views in Zabbix when on-call staff already work there and the view depends on problem state, acknowledgment or host inventory. Move a view to Grafana when it combines Zabbix with other data sources or when a wider audience needs one place to look. Most teams end up with both: Zabbix for operations and Grafana for shared reporting. Decide each view by its owner, its audience and its data sources, and record that decision in the written scope. Avoid building the same view in two places, because two copies drift apart and someone has to maintain both. Review the split after the first production incident, since that is when gaps in each tool become visible.
How DeployOpen scopes and delivers the Zabbix and Grafana work
DeployOpen plans and builds Zabbix and Grafana dashboards inside infrastructure you control, starting from a written scope that names the data source, users and dashboards. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ongoing support is available as a retainer for changes after go-live.
How we scope
- The written scope names the Zabbix hosts, items and problem data each Grafana panel will read.
- It lists which dashboards must stay inside Zabbix and which move to Grafana, with reasons.
- It defines who gets Grafana access, how per-user tokens are issued and which Zabbix roles map to each group.
How we build
- Install the Grafana Labs Zabbix plugin and configure the data source against your Zabbix API endpoint.
- Build problem panels, host group views and trend dashboards, then test each panel against known test data.
- Provision data sources and dashboards as code so changes are reviewed and repeatable across environments.
How we hand over
- Hand over a document covering data source settings, token handling, role mapping and dashboard ownership.
- Walk your operators through panel logic, filters and how problem data is refreshed and interpreted.
- Record which Grafana version and Zabbix plugin version were deployed, so upgrades start from a known state.
How we support
- Plan Grafana and Zabbix upgrades separately, checking plugin compatibility before each version change.
- Review role mappings and token rotation when people join, move teams or leave the organization.
- Retainers can cover dashboard changes, upgrades and continuous testing once dashboards are live.
