Wazuh and Elastic Stack integration guide

Wazuh and Elastic Stack integration: what it does and when it fits

The Wazuh and Elastic Stack integration forwards Wazuh alerts through Logstash into Elasticsearch, and it requires index template and field limit changes in Elasticsearch plus the Kibana dashboards that Wazuh provides. It fits teams that already run Elasticsearch and Kibana and want Wazuh alerts next to firewall, application and cloud logs, so one search surface and one set of dashboards support investigations. The work is less a plug-in than a set of changes to a shared cluster, so the people who own that cluster need to be part of the decision from the start. Alerts that reach Elastic also inherit that cluster's sizing, retention and access model.

Wazuh stores alerts in its own indexer by default, so the first decision is what the Elastic deployment will be for. In a copy model, Wazuh keeps its indexer as the working store and Elastic receives a duplicate for searches across log sources, which means the alert data is stored twice. In a replacement model, Elastic becomes the alert store and the Wazuh indexer is retired, which changes how the Wazuh dashboard and its compliance views are used and needs its own testing. In a second analysis path, both platforms analyze the same alerts for different teams. Write down which team triages alerts, where retention is set for each copy, and which system an auditor will be pointed to.

The method is the one the Wazuh documentation describes for Elastic Stack, and it runs across the Wazuh server, Logstash and your Elasticsearch cluster. Confirm the exact steps for your Wazuh 4.14 patch level before you start, because patch releases in the 4.14 line have arrived roughly every one to two months and the steps must match the version you deploy. Check that the Logstash version you install is supported with the Elasticsearch version you run, and test the index template and field limit changes on a non-production cluster first. A wrong mapping can cause later alerts to fail to index, and the failure may not be visible in the Kibana dashboards until data is missing.

Plan the Elastic side as its own project. The default Elastic distribution is licensed under the Elastic License 2.0, and AGPLv3 is offered as an OSI-approved option according to Elastic's licensing FAQ, so confirm which license and subscription tier your existing deployment uses. The tier matters because single sign-on, field- and document-level security and other access controls depend on it, and Wazuh alerts often contain host names, user names and file paths that need restricted access. Ask any partner for a quote that separates Logstash and Elastic node work, template and dashboard testing, storage for the copy you choose, and the recurring effort to keep the pipeline working through Wazuh and Elastic upgrades.

What you need in place before connecting Wazuh to Elastic

Most delays in a Wazuh and Elastic Stack integration come from decisions made late: which versions to pin, where Logstash runs, and how components authenticate to each other. Settle these six items on paper before anyone edits a pipeline or opens a firewall rule.

Wazuh release line and version pin

Wazuh 4.14 is the current release line, and 4.14.9 was released on 14 October 2026. Pin one patch level for both the pilot and the production build, then read the release notes for that patch before scheduling any change. Patch releases have shipped roughly every one to two months, so schedule a repeatable upgrade window for each one and retest the integration after every patch.

Working Wazuh server and indexer

Confirm that the Wazuh server, the Wazuh indexer and the Wazuh dashboard are installed and healthy, with at least one agent reporting. The indexer stores the alerts that Logstash will forward, so verify that alerts reach it before adding a second destination. Record the installation method you chose, such as the step-by-step installation, the OVA or a container build, because certificate paths and file locations used later depend on how the components were installed.

Elasticsearch and Kibana versions

Choose the Elasticsearch and Kibana line before building anything. Elastic's current 9.x releases, 9.5.5 and 9.4.8, came out on October 6, 2026, and 8.19.23 is still maintained. Elastic lists end of maintenance for the 8.x line on January 15, 2027 and for the 9.x core stack on October 15, 2027, so plan the upgrade path before go-live. Confirm in the Wazuh documentation which Logstash and Elasticsearch versions it supports.

Logstash placement and ownership

Decide where Logstash runs, which host or container owns its pipeline, and who patches it. It sits between the Wazuh server and Elasticsearch, so it belongs to both the Wazuh and the Elastic change processes. Size its CPU, memory and disk for the alert volume you expect, and confirm its version against the Wazuh documentation's supported list. Keep pipeline configuration under version control so index template and field limit changes can be reviewed with it.

Network paths between components

Map each connection before opening firewall rules: Wazuh server to Logstash, Logstash to Elasticsearch, and analyst access to Kibana. Open only the paths the pipeline needs, and limit each one to specific source hosts and the Elasticsearch HTTP port your cluster uses. Check whether proxies, load balancers or network segmentation sit in the path, since they can change TLS termination and connection timeouts. Record the paths in the design document so the security team can review them.

TLS certificates and service accounts

Decide which certificate authority signs the certificates for Logstash and Elasticsearch, and who renews them. Each connection that carries alerts should use TLS with certificates that name the hosts involved. Create a dedicated Elasticsearch user for Logstash with only the privileges its index writes require, and keep administrator and Kibana accounts separate from it. Store the credentials in your secrets manager and set a rotation date before go-live.

How Wazuh alerts travel into Elasticsearch

Alerts reach Elasticsearch through a fixed chain of four stages, and the team should be able to name the component responsible for each stage before building any dashboards. Wazuh agents installed on endpoints collect events and send them to the Wazuh server. The server runs decoders, which parse each raw event into named fields, and then applies rules, which decide whether an event matches a condition worth alerting on and at what severity. Only matching events become alerts. The Wazuh indexer stores those alerts as searchable records, and the documented forwarding method then moves alert records from the indexer into Elasticsearch indices through Logstash. Because every stage can drop, reshape or delay data, a missing alert in Kibana can originate at any of the four points, so troubleshooting should follow the same order as the data path.

Logstash sits between the Wazuh indexer and Elasticsearch as the transport and transformation point. It reads alert records from the source the Wazuh guide specifies, applies the filters the pipeline defines, and writes the results to the index names the pipeline sets. What it adds is a separate, configurable layer: field renaming and type handling, a buffer when the destination slows down, and a place where index naming and routing can be controlled. The cost is one more service to install, patch, monitor, secure with TLS and size for the alert volume your rules generate. Teams that already run Logstash for other data should assign clear ownership of the Wazuh pipeline so that changes to it do not affect unrelated flows.

Before writing any pipeline, confirm the details in the Wazuh documentation for the release line you run. The current supplied line is 4.14, and patch releases arrive roughly every one to two months, so configuration examples can change between patches. Check which output plugin the guide names for sending alerts to Elasticsearch, which file or index the input reads, how the pipeline configuration files are laid out and where they must sit on the Logstash host, and which authentication and TLS settings it expects. Record the exact Wazuh release you tested against. If a guide example uses a setting that your Elastic version does not support, resolve it against the vendor documentation before going further.

Plan a controlled test before the rollout. Send alerts from one agent through the full chain, then confirm in the destination index that a single alert record arrives with the fields your analysts expect and that its timestamp reflects the event time. Decide which Elastic deployment receives the data and who owns it. Confirm the Elastic subscription tier you hold, because Elastic's published facts show that TLS and the file and native user realms are free in the Basic tier, while single sign-on and field- and document-level security sit in paid tiers. Those limits shape who can read alerts in Kibana. Finally, agree how Logstash failures will be detected, since a stopped pipeline can look like a quiet environment.

Which Elastic license and subscription tier fits your team

Elasticsearch and Kibana source code is offered under three licenses, and the license you accept determines what you may do with the code. The default distribution has been under the Elastic License 2.0 since 2021. According to Elastic's licensing FAQ, the same source is also available under SSPL 1.0 and, since AGPLv3 was added in September 2024 before the 8.16 release, under AGPLv3.

Elastic License 2.0 (ELv2): the default distribution that most users download unless they choose otherwise.
SSPL 1.0: a source-available option that Elastic lists alongside the other two.
AGPLv3: added by Elastic to offer an OSI-approved open source option.
Build and version: confirm which license applies to the exact package and version you plan to deploy, since the default and alternative builds can differ.

Before your architecture is fixed, have your legal team read the license text and confirm the build that will run in your environment, including any Kibana plugins you intend to add.

Configuration sequence for the Wazuh to Elastic pipeline

This sequence sends Wazuh alerts through Logstash into an existing Elasticsearch and Kibana deployment. Each step closes with a check the team can repeat, so a failure surfaces at the step that caused it. The result is an alert pipeline that is secured, indexed and visible in dashboards before production alerts depend on it.

Confirm versions and licensing
The platform owner compares the Wazuh release in use with the Elasticsearch, Logstash and Kibana versions planned for the deployment, using the compatibility guidance in the Wazuh documentation, and confirms that each version is supported. Elastic's default distribution is licensed under the Elastic License 2.0, and AGPLv3 is offered as an open source option, so the organization should record which license applies. Features such as field-level security sit in paid tiers, and end-of-life dates differ by release line, so check both before design begins. The step is complete when a signed version matrix and license note exist.
Create dedicated Elasticsearch roles and users
The Elasticsearch administrator creates a role limited to writing to and managing the indices Wazuh uses, plus a separate service user for Logstash, so no administrator credentials sit in the pipeline. Role-based access control and the native user realm are part of the free tier, so this step does not require a subscription change. The team records the privileges granted, the owner of the password and how it is rotated. The step is done when the Logstash user can write a test document to the target index and cannot read unrelated indices.
Set up TLS between components
The engineer issues certificates for the Elasticsearch nodes and the Logstash host from the organization's certificate authority, then configures Elasticsearch to require TLS on its HTTP and transport layers. Logstash is set to trust that authority and verify the Elasticsearch hostname, and the Wazuh side is configured to connect to Logstash over TLS as the Wazuh documentation describes. Keep private keys out of shared repositories and restrict file permissions to the service account. The check is a verified connection from the Logstash host with a valid certificate chain, and a refused connection when a certificate from the wrong authority is presented.
Install and configure Logstash output
The engineer installs Logstash on a host that can reach both Wazuh and Elasticsearch, then adds the pipeline configuration that Wazuh documents for its alert output, with the service user and certificate paths set. Plugin versions should match the Logstash release in use. If the Wazuh documentation provides a way to test the configuration before enabling it, use it. The check is that Logstash reports the pipeline as running in its logs and monitoring endpoint, with no connection or mapping errors during the first startup.
Apply the Wazuh index template
The Elasticsearch administrator loads the Wazuh index template and applies the field limit change that the Wazuh documentation specifies for the alerts index, so new documents map fields as Wazuh expects. Apply changes through the cluster's documented API and record the previous values so they can be reverted. Indices created before the change may need reindexing or a rollover, so confirm that approach with the Wazuh documentation. The check is that the template appears in the cluster's index template list and the field limit setting reads back correctly on the target index.
Send a test alert and confirm indexing
The Wazuh administrator generates a test alert on an enrolled agent, using a rule test or a harmless event that the Wazuh documentation describes. The engineer then searches the alerts index in Elasticsearch for that agent name and rule identifier. Compare the document's timestamp and fields against the same alert shown in the Wazuh dashboard. The step closes when the test document appears in the expected index with matching fields, and any difference in timing between the two views is understood and documented.
Import the Wazuh Kibana dashboards
The Kibana administrator imports the dashboards Wazuh provides, using the dashboard package that matches the Wazuh release in use, and points them at the index pattern created for Wazuh alerts. Check that the saved objects import without errors and that the index pattern resolves to the alerts index from the previous step. Confirm role access so only the intended groups can open the dashboards. The step is complete when at least one panel shows the test alert from the earlier check.
Enable the pipeline for production alerts
The platform owner switches the Wazuh output to the production route, confirms the rollback steps and the owner of each component, and watches Logstash queue behavior, Elasticsearch disk use and index growth against the capacity plan. Set alerts on pipeline health so failures are noticed quickly. Production alerts should flow only after the team accepts the observed volume and retention. The step is complete when live alerts from enrolled endpoints appear in the index and on the dashboards, and the on-call owner signs off on the monitoring.

How Wazuh alert fields map to Elasticsearch indices and dashboards

This table compares each common Wazuh alert field with the Elasticsearch index, template or dashboard setting that receives it. Read each row as a check to run against sample alerts from your own Wazuh version before the Kibana dashboards go live. The main takeaway is that dashboard panels can fail silently when a field name or type differs, so confirm mappings first.

Wazuh source field or output	Elasticsearch target	Purpose	What to check
agent.name	Agent name field in alert documents in the wazuh-alerts indices, mapped as a keyword	Identifies the endpoint that produced each alert for host filters	Confirm the exact field name and mapped type in a sample alert JSON from your Wazuh version
rule.id	Rule identifier field in alert documents	Groups alerts by detection rule for tuning and dashboard panels	Confirm the stored type matches what the provided dashboard visualizations expect
rule.level	Numeric rule level field in alert documents	Drives severity filters and threshold panels	Confirm the field is numeric, since a text-typed level breaks range queries
rule.groups	Array field of rule group labels in alert documents	Supports filtering by category such as authentication or file integrity	Check that array values are indexed and searchable as the dashboards assume
timestamp	The @timestamp field, set from the alert time and used for index time selection	Sets time-based dashboard ranges and the time field of the index pattern	Confirm timezone handling and that the index pattern names the same time field
Decoder-derived fields such as decoder.name, data.* and full_log	Document fields under data.* and the full_log text field	Carry decoder output used by custom rules, searches and log-source panels	List the decoder fields each log source produces and map new ones before ingestion
Index template for wazuh-alerts indices	Index template applied to new wazuh-alerts indices at creation	Sets field types and index settings before the first document arrives	Load the template that matches your Wazuh version and review field types and limits
Index pattern used by the Kibana dashboards	Kibana index pattern matching the wazuh-alerts index naming	Connects the provided dashboard panels to the alert indices	Confirm the pattern matches your index names and that every panel loads without field errors
Field mapping conflicts from prior indices	Existing indices that hold older mappings for the same field names	Makes a field searchable in one index and missing or mistyped in another	Compare mappings across indices and plan reindexing or a new index before changing the template

Why index template and field limit changes matter for Wazuh data

The index template and the Elasticsearch field limit decide whether Wazuh alerts are stored intact, so both belong in the plan before the first alert is forwarded through Logstash. Wazuh alerts carry many nested fields, and many of them come from the decoders and rules on the Wazuh server, so the set of fields varies by event source. If the index template does not define mappings before data arrives, Elasticsearch infers field types from the first documents it sees. A later document that sends a different type for the same field can then be rejected. Separately, once an index holds more distinct fields than its configured total field limit (the index.mapping.total_fields.limit setting), documents that would add new fields are rejected. Confirm this setting and its default in the Elasticsearch version you run, and check how your Wazuh indexer and Logstash pipeline handle rejected documents.

Once rejections appear, you have two options: raise the field limit or reshape the data. Raising the limit is fast, but every new field adds a mapping entry that the cluster must hold and that queries must consider. Reshaping means changing the Logstash pipeline so it drops, renames or restructures decoder output that no dashboard, search or rule uses, or keeps only a defined set of fields under known paths. Start by listing which fields your Kibana dashboards, saved searches and detection workflows actually query. Fields that nothing reads are the first candidates for removal. Record the decision and its reason, because the next Wazuh upgrade may add fields and the same question will return.

Raising the limit without capacity planning is the most common way this change goes wrong. A higher ceiling lets the mapping grow without a boundary, and a large mapping increases cluster state size, memory use on data and master nodes, and the time needed to create or update indices. Dynamic mapping also means that field names taken from event content can grow the mapping over time, which makes the growth harder to predict. Before changing the limit, ask the team that runs the cluster to confirm heap sizing, shard count per index, index rollover settings and retention against the higher ceiling. Set an alert on the field count per index so that growth is visible before documents start failing.

Test the template and limit against a copy of real alert shapes before production use. Use a sanitized export from your existing alert index, or events produced by a non-production Wazuh environment, and include the rare cases: large nested events, decoders for each agent platform you run, and alerts from agentless sources such as firewalls. Load them into a test cluster that uses the same template, limit and Logstash pipeline as production. Watch for rejected documents in the Logstash and Elasticsearch logs, then confirm that the Kibana dashboards show the expected values. Repeat this test after each Wazuh upgrade, because decoder and rule changes can add fields that the production index has never seen.

How to secure the Wazuh to Elasticsearch connection

The Wazuh alert path crosses several components, and each handoff carries credentials and data. The cards below cover the transport, the account model, the secrets Logstash uses, and the controls that depend on your Elastic subscription tier, so you can decide which of them your team will build and confirm before the pipeline goes live.

Encrypt every hop with TLS

Wazuh components, Logstash, Elasticsearch and Kibana each pass data to the next one, so every connection needs TLS with certificate verification enabled. Check that each client trusts your internal certificate authority, that hostnames match the certificate names, and that no plaintext listener remains open. Elastic made TLS free in the Basic tier with versions 6.8.0 and 7.1.0, so confirm the Elastic version in your cluster before you plan the design around it.

Dedicated write role for Logstash

Create a Logstash user whose privileges cover only writing to the alert indices the pipeline uses, plus any template access the pipeline requires. Do not reuse the elastic superuser or an administrator account for ingestion. Compare the role's index patterns with the index names your pipeline actually writes, then test that the account is refused on other indices before you move to production.

Separate Kibana readers from writers

Analysts and dashboard users should sign in with roles that read alert indices and nothing more, while the Logstash account holds write rights only. Keep these credentials in separate user records, so a leaked reader password cannot push events and a leaked pipeline secret cannot browse dashboards. Confirm how your Elastic version assigns Kibana space and feature privileges before you map teams to roles.

Rotate certificates and pipeline secrets

Logstash configuration often references the Elasticsearch password, a keystore passphrase and certificate paths. Move these values into the Logstash keystore or a secrets manager your team already operates, restrict read permissions on pipeline files, and record who can open them. Plan certificate renewal ahead of expiry, rehearse the reload on a staging node, and confirm how your Logstash version handles changed certificates without downtime.

Confirm tier-dependent security controls

Single sign-on, field-level security and document-level security depend on your Elastic subscription tier. Elastic's self-managed subscriptions page lists these alongside encryption at rest and FIPS 140-3 mode, and it states that the Platinum tier is no longer available to new customers. Ask Elastic which tier covers each control you need, and record the answer before design sign-off.

Audit changes to templates and dashboards

Index templates, field mappings and Kibana dashboards shape how alerts are stored and what analysts see, so their changes need an audit trail. Limit who can create or edit index templates and saved objects, and confirm whether your tier includes Elasticsearch audit logging for those actions. Export dashboards to version control, and review the change history before each Wazuh upgrade, since provided dashboards and mappings may change between releases.

Failures that stop Wazuh alerts from reaching Kibana

This table pairs each symptom seen after connecting Wazuh to Elasticsearch and Kibana with its likely cause and the first fix to try. Before changing anything, check the Logstash logs, the rejection responses Elasticsearch returns for bulk writes, and the alert output on the Wazuh server to see which stage is failing.

Symptom	Likely cause	Fix
No documents arriving in Kibana	Logstash is stopped, its output points to the wrong Elasticsearch host, or TLS trust or the output credentials fail	Check the Logstash service and its logs first, then confirm the output host, the CA certificate and the user's write privileges
Documents rejected with mapping errors	A field arrives with a type that conflicts with the existing index mapping, or the index has reached its total field limit	Read the rejection reason in the bulk response, fix the conflicting field in the index template, and raise the field limit only after reviewing the new fields
Dashboards show no data	The Kibana index pattern does not match the alert index names Logstash writes, or the time filter excludes the data	Match the index pattern to the output index naming, widen the time range and confirm that documents appear in Discover
Duplicate alerts after a restart	Logstash re-reads the alert file because its read position was lost or stored on non-persistent storage	Keep the file input position store on persistent storage and set the document ID from a stable alert field so re-sent events overwrite the existing document
Timestamps appear shifted	Kibana displays times in the browser time zone, or the date filter parses the Wazuh timestamp with the wrong offset	Confirm the time zone on the Wazuh server, configure the date filter to use the source timestamp offset and compare one alert in both systems
Index size grows faster than planned	Broad rules raise alert volume, duplicate events are indexed, or no lifecycle policy removes old indices	Measure daily document counts by rule group, tune rule levels and filters on the Wazuh side, and apply the index lifecycle policy your retention rules require

What buyers ask before connecting Wazuh to Elastic

How much does a Wazuh and Elastic Stack integration cost?

The cost is set by a written scope, and DeployOpen does not publish a price list. The main components are planning and version checks, Logstash pipeline and index template work, dashboard setup, testing, and handover to your staff. Wazuh is distributed under GPL version 2 and has no license fee for self-hosted use. Elastic cost depends on your subscription tier and existing contract. Infrastructure for added storage and processing is paid in your own environment. Ask the quote to separate one-time work from recurring items such as upgrades or support retainers, and to name the Elastic features the dashboards depend on.

What drives the effort in a Wazuh to Elastic integration?

Effort rises with how many components must agree and how much data must be reshaped. Version alignment between Wazuh, Logstash and your Elasticsearch and Kibana release is the first driver. Number of sources, such as agent groups and syslog or API-based devices, changes pipeline complexity. Field mapping and index template changes, including any field limit adjustments, take time to test against real alert shapes. Dashboards need import, validation and adaptation to your naming. Tier features such as single sign-on, field-level security or anomaly-based alerting add configuration and licensing checks. Ask for each driver to be listed as a separate line in the scope.

Can our own team connect Wazuh to Elastic without a partner?

Yes, a team with experience in both platforms can build the integration in-house, provided it has time and a place to test. The documented path covers the Logstash output, the index template and the Kibana dashboards, but the hard parts are version matching, mapping decisions and sizing the pipeline for your alert volume. Teams often underestimate the testing and the cutover coordination between the two sides. A partner is useful when your staff lack hands-on experience with either product, or when deadlines conflict with other work. Decide by comparing your staff's skills and availability against the written stages in the scope.

How long does a Wazuh and Elastic integration take, stage by stage?

Timing depends on the stages below, and each one should carry its own dates in the written plan. First comes scope and version checks, where Wazuh, Logstash and Elastic versions are confirmed against the vendor compatibility notes. Next is a lab build that mirrors your production versions. Then comes pipeline and index template work, followed by dashboard import and validation against sample alerts. The last stages are cutover, monitoring and handover. Delays usually come from access approvals, change windows or unresolved mapping questions, so ask for each dependency and its owner to be written down.

What do our Elastic and Wazuh administrators need to provide?

Both teams must contribute, and the work stalls if either is missing. Your Elastic administrators provide access to the cluster, role and index design decisions, retention and index lifecycle preferences, and approval for changes to templates and field limits. Your Wazuh administrators provide access to the Wazuh server and indexer configuration, agent group details, and approval for changes to alert forwarding. Both teams need a test environment that matches production versions and enough sample data to exercise the pipeline. Ask the scope to name a contact for each role and to state when their time is needed.

Does Elastic licensing change whether we should integrate Wazuh?

Licensing affects which features you can use, not whether the integration is possible. Elasticsearch and Kibana are offered under Elastic License 2.0 by default, with an AGPLv3 option added in September 2024 before the 8.16 release. Elastic has said the default distribution has used ELv2 since 2021. Since May 2019, TLS, native users and role-based access control have been free in the Basic tier, while single sign-on and field-level security sit in paid tiers. Elastic says the Platinum tier is no longer offered to new customers. Confirm your entitlements with Elastic before you design the dashboards and access model.

Does Elastic 8.x end of maintenance affect our integration plan?

Yes, if your cluster runs 8.x, the timing should shape the plan. Elastic's end-of-life page lists end of maintenance for 8.x on January 15, 2027, with 8.x support ending July 15, 2027. The core 9.x line has end of maintenance on October 15, 2027. Elastic's page should be checked again before you commit to dates, because support windows can change. Plan the target version first, then confirm that your Wazuh release supports it in the Wazuh compatibility documentation. If the target version is not yet supported by Wazuh, the plan needs a sequencing decision before the build starts.

How DeployOpen scopes and delivers the Wazuh to Elastic integration

DeployOpen approaches the Wazuh to Elastic Stack integration as a planned change to your existing Elasticsearch and Kibana deployment, inside infrastructure you control. The work covers the Logstash pipeline, index template and field limit changes, and the provided Kibana dashboards. Engagements are fixed-scope, with scope agreed in writing before work starts.

How we scope

The written scope names the alert outputs, Elasticsearch and Kibana versions, and the Logstash hosts involved.
Scope lists the indices, index template fields and dashboards to be created, changed or left alone.
Scope confirms which Elastic license and subscription tier your deployment runs, since security features depend on it.

How we build

Logstash pipeline configured to receive Wazuh alerts, with inputs, filters and outputs documented for your operators.
Index template and field limit changes are drafted, tested against sample alerts, and applied in a staged order.
Kibana dashboards are imported and checked against your indices, roles and data views before go-live.

How we hand over

Written runbook covering pipeline configuration, index template version, field limit settings and dashboard import steps.
Validation record showing alerts arriving in the expected indices, fields mapped as designed and dashboards populated.
Knowledge transfer session for your Wazuh and Elasticsearch administrators, with questions captured and answered in writing.

How we support

Retainer support is available for Logstash, index template and dashboard maintenance after handover.
Upgrades of Wazuh, Logstash and Elastic Stack components are planned as separate scoped work, with backups taken first.
Confirm your Elastic cluster design, including the master-eligible node count needed for high availability, before scope is agreed.

Wazuh and Elastic Stack integration