Originally published on LinkedIn. Lightly edited for clarity.
Wazuh upgrades look simple on paper, but real environments have custom rules, older agents, and fragile dashboards.
The 4.8.0 upgrade is not just a package bump. It is a coordination exercise across the manager, indexer, dashboard, and agents.
Know the moving parts
A Wazuh deployment is at least four systems:
- Manager for processing rules, decoders, and alerts.
- Indexer for search and storage.
- Dashboard for visualizations.
- Agents for endpoint telemetry.
When these drift out of alignment, you get missing data, broken dashboards, or noisy alerts.
Common upgrade pitfalls
- Version skew. Agents too far behind the manager can stop sending data or trigger unexpected rule behavior.
- Custom decoders and rules. Local overrides can conflict with updated rule sets.
- Indexer changes. Templates, mappings, or retention policies can break dashboards after an upgrade.
- Dashboards and saved objects. New versions can require re-import or migration steps.
Treat each of these as a first-class dependency, not an afterthought.
A practical upgrade order
A conservative approach is:
- Upgrade the indexer cluster and verify search health.
- Upgrade the manager and validate rule processing.
- Upgrade the dashboard and confirm saved objects load.
- Roll agents in phases, starting with a small cohort.
This order keeps storage and processing stable before you move the edge.
Validation checklist
After each phase, validate:
- New alerts are indexed and visible.
- Agent status is healthy and consistent.
- Custom rules and decoders still fire as expected.
- Dashboards reflect current data.
If any of those fail, stop and fix before continuing.
2026 Perspective
Wazuh upgrades are smoother today, but the hard part is still the same: reduce surprises by staging and sequencing.
Automation around upgrades and regression checks pays off quickly. If the upgrade plan is a runbook instead of a fire drill, you are doing it right.