Wazuh indexer sizing and data retention guide

Why Wazuh indexer sizing decides your storage bill

If your organization must keep Wazuh alerts for a set period under a log retention rule, the indexer sizing and retention policy you choose together determine how fast your disk grows and how many indexer nodes you will eventually need. Treat them as one decision. A generous retention window on an undersized indexer fails in the same way as a right-sized indexer with no retention limit: both lead to unplanned storage purchases or an emergency rebuild. The problem is harder than it looks because the inputs are not fixed. Event volume depends on how many endpoints report, which operating systems and applications they run, which log sources you forward, and how noisy your rules are. A Linux fleet with auditd enabled, a set of Windows servers shipping security event logs and a few firewalls sending syslog produce very different loads, even at the same endpoint count. Your estimate has to follow the log sources you actually plan to onboard, not only the number of hosts on your inventory list. Sizing done before agents are enrolled is usually wrong for the same reason. Early estimates rely on assumptions about event rate per endpoint that rarely survive contact with production. Enroll a representative pilot group first, run it through the full pipeline, and measure daily index growth per source for at least a few business cycles. Then project forward with the growth you expect from new sources, not just new hosts. Ask your implementation partner or internal team to document the measurement method so the figures can be repeated when the estimate is reviewed. Keep two data types separate in your model. The Wazuh indexer is the component that stores alerts, and alerts are not the same as the raw archived events that some retention rules also require. Alerts are what the dashboard queries daily, while archives are usually cheaper, slower storage kept for evidence. Confusing the two is a common route to paying hot-storage prices for data nobody searches. Decide which records your rule requires, how long each must be kept, and where each lives before you choose index settings. Before you commit to node counts or disk sizes, confirm the sizing guidance and the index management options in the Wazuh documentation for the 4.14 line that you will deploy, and check that the version you install matches it. Ask the vendor or your partner to walk through the calculation against your own measured data, and record the assumptions in writing so that a later change in endpoint count or log sources triggers a new estimate.

Which Wazuh components write data the indexer must hold

Four Wazuh components feed one data path, and only some of what they handle ends up stored in the indexer. Sizing starts by knowing which component writes what, and which settings control how much reaches the indexer.

The Wazuh indexer holds alerts

The indexer is the full-text search and analytics engine where alerts are stored and queried. It is the component whose disk, memory and node count you size for retention. Confirm which index patterns your deployment creates and how many nodes you plan to run before estimating storage, because each node and index carries its own capacity needs.

The Wazuh server applies rules

The server analyzes agent data with decoders and rules and decides which events become alerts. Its rule configuration determines the volume the indexer receives, so custom rules and rule levels are part of sizing, not only detection. Review the rule set you plan to run and the alert levels you will keep before sizing the indexer.

Agents generate the raw events

Wazuh agents on Linux, Windows, macOS, Solaris, AIX and HP-UX produce the raw endpoint events that enter the pipeline. The number of agents and the operating systems they run set how much raw data the server must analyze. Most raw events never reach the indexer, so inventory the fleet by operating system and planned log sources first.

Agentless syslog sources add volume

Devices such as firewalls can send data through syslog collection or periodic API probing without an installed agent. These sources often produce high event counts that are easy to overlook in a sizing exercise. List every agentless source, its expected event rate and the rules that apply to it before deciding on indexer capacity.

The dashboard reads indexer data

The Wazuh dashboard is the web interface that queries the indexer for alerts, dashboards and compliance views. It adds query load and user activity to the indexer but does not write alert data. Record the number of dashboard users, the saved searches and the compliance views you plan to use, since heavy querying affects node resources.

Server cluster scaling and retention settings

The Wazuh server can run as a cluster to scale horizontally, which changes how analysis load is spread but still feeds one indexer. Document your planned server node count, the retention period your compliance rules require and the archive method you will use. These inputs decide how long alerts stay in the indexer before rotation or archive.

How event volume turns into index storage

Storage planning for the Wazuh indexer starts from the alerts it stores, not from the raw log volume your sources produce. The chain runs from endpoint events collected by Wazuh agents, to decoded events produced by the Wazuh server's decoders, to alerts raised when rules match those decoded events. Only the alerts, along with the archived or indexed data your configuration keeps, land in the indexer's storage. Raw log volume can be large while alert volume is modest, or the reverse, depending on which rules fire and how often. That is why the figure to measure is the alert volume per day at each rule level, multiplied by the average stored size per alert in your own environment, and not a volume taken from a log dashboard or a generic estimate.

Several factors move the total, and each one should be recorded during the pilot. The number of enrolled agents sets the base rate of events. The log sources that feed the server, including syslog from firewalls and other agentless devices, add decoded events with their own rule matches. The number of rules that fire at each alert level changes both the count and the size of stored documents, so custom rules and noisy default rules need to be reviewed before the baseline is taken. File integrity monitoring and the software inventory used by vulnerability detection also add documents on every change or scan cycle. Retention is the multiplier that turns a daily rate into a stored total, so the number of days each index is kept must be fixed before any calculation is done.

Build the baseline from a pilot period that runs on the systems you intend to monitor, with the same rules, decoders and agent groups you plan to use in production. Record daily alert counts by level and by source, and the on-disk size of the indexes they produce. Capture enough days to include your normal weekly cycle, such as business days and weekends, and any batch jobs or scheduled scans that create spikes. Then extrapolate to the planned agent count and source count, and apply a stated growth margin for new sources, new rules and seasonal peaks. The margin is a decision, not a technical constant. Agree its size and the reasoning behind it with your storage team, because they own the disk, replication and backup assumptions that the figure feeds.

No default volumes are assumed in this method. Vendor examples, community figures and figures from other environments can show the kind of load to expect, but they do not describe your fleet, your rules or your retention rules. Ask the implementation team to show the pilot data, the calculation and the assumptions in writing before any hardware or cloud storage is ordered. Confirm with the Wazuh documentation for the 4.14 line how the indexer handles replicas and shards for your chosen layout, since those settings change the stored total on disk. Treat the result as a figure to be re-measured after go-live, because the first production weeks often show new alert patterns that the pilot did not include.

Which indexer layout fits your retention and growth plan

This table compares four indexer layouts and two retention approaches for a Wazuh deployment. Read each row for when the option fits and what it adds to hardware, patching, cluster health and retention management. The main takeaway is that layout and retention decisions should be made together, and the final choice must be checked against the Wazuh documentation for the 4.14 line.

Option	When it fits	Operational cost	What to confirm
Single indexer node	Small estate with modest alert volume, one team owns the stack, and downtime of the search tier is tolerable for a short period	Lowest hardware and patching effort, but no node redundancy, so disk growth and a node failure both stop alert storage and search	Single-node support and supported storage sizing for 4.14 in the Wazuh documentation
Multi-node indexer cluster	Growing estate, alert retention needed for longer periods, or a requirement for resilience of the search and storage tier	Extra nodes, certificates, cluster health checks, shard and replica monitoring, and coordinated rolling patches	Minimum node count, replica settings and cluster sizing guidance for 4.14
Separate indexes per data class	Compliance evidence, routine alerts and high-volume low-value events have different retention needs	Index templates, lifecycle rules and dashboard index patterns to maintain for each class, plus review when new sources are added	Index management and lifecycle policy options available in your 4.14 indexer version
Hot-warm storage tiers	Infrastructure already offers fast and cheaper storage, and older alerts are searched rarely	Tier assignment rules, node attributes, data movement checks and more storage classes to budget and back up	Whether the chosen 4.14 setup supports tier allocation and how it interacts with your archive plan
One retention rule for all alerts	Simple policy where every alert class must be kept for the same period	Easy to explain and audit, but keeps noisy low-value data as long as evidence, which raises disk use	Retention period set by your legal, contractual and internal policy owners
Separate rules for evidence and noisy data	Compliance evidence must be kept for a defined period while low-value events can expire sooner	Requires tagging or routing of data by class, regular review of rules, and documented justification for each class	Compliance retention requirements agreed with your assessor, and index naming supported in 4.14

Sizing and configuring retention in the right order

This sequence moves from what generates data and what must be kept to how the indexer is laid out, sized and configured, so that retention settings reflect measured volume and written obligations rather than guesses. Each step ends with an observable artifact that the next step depends on.

Inventory agents and log sources
List every endpoint type, server role, network device and syslog source that will send data to Wazuh, including which agents will run and which devices will be monitored agentlessly through syslog collection. Record the owner of each source and the event types it produces, since agentless devices and agent-based hosts generate volume very differently. Done means a signed-off inventory that the platform owner and the source owners have both reviewed, with any gaps marked for follow-up.
Collect a measured baseline from a pilot
Enroll a representative subset of the inventory, covering each source type, and run it for a period long enough to see normal weekday and weekend patterns. Measure alerts per day and stored bytes per day from the indexer, not from estimates, and note any spikes caused by scans, patch cycles or noisy rules. Done means a baseline report that states the measured daily figures per source type, the method used to measure them, and the assumptions behind the extrapolation to full scope.
Write the retention matrix
Document every retention obligation that applies to the data: regulatory requirements, contractual commitments to customers or partners, and internal policy. For each data class, record the minimum time online in the indexer, the total time it must be kept, who may access it, and whether it must be retrievable in its original form. Confirm the obligations with legal, compliance and the relevant contract owners, because the auditor or regulator will judge the matrix, not the platform team. Done means a written retention matrix approved by the compliance owner.
Choose the indexer layout
Decide the number of indexer nodes, how shards and replicas will be distributed, and whether the deployment will be single-node or clustered, using the matrix and baseline as inputs. Confirm the approach against the Wazuh deployment and indexer documentation for the 4.14 release line, including the supported topologies and any restrictions on node roles. Record the chosen layout and the reasons for each decision. Done means a layout decision record that the team can explain to an auditor and that cites the version of the documentation used.
Size storage with margin and confirm node counts
Multiply the measured daily volume by the online retention period from the matrix, then add replica copies, indexing overhead and a free-space margin that your operations team agrees to hold. Compare the result with the node counts and storage guidance in the Wazuh documentation for your chosen layout, and document where your figures differ and why. Ask the vendor or your implementation partner to confirm any figure the documentation does not state. Done means a sizing worksheet with the formula, inputs, margin and confirmed node count, reviewed by the platform owner.
Configure index retention and rollover
Set index lifecycle rules so that indices roll over at defined size or age thresholds and are deleted or moved according to the retention matrix. Apply rules to each data class separately, so that high-volume, low-value events do not hold the same retention as high-value alerts. Create a test index, feed it synthetic or pilot data, and confirm that it rolls over and that the deletion or move step runs as configured. Done means a test index that rolls over and expires as designed, with the policy definitions saved in version control.
Define the archive path
For data that must outlive the indexer, define where it goes, in what format, how it is encrypted and how it is indexed for later retrieval. Choose the archive tier, such as object storage or offline media, based on retrieval needs and the matrix, and write the export procedure that runs before deletion. Restore a sample of archived data into a separate environment and confirm that it can be read and that its integrity is verified. Done means a successful archive restore test with the restore time and any gaps recorded.
Load test and confirm headroom
Run a load test on a cluster built to the chosen layout, pushing event volume above the measured baseline to the peak you expect, including the rollover and deletion jobs running at the same time. Watch disk usage, JVM heap pressure and indexing latency throughout, and confirm that the margin set in the sizing worksheet holds under peak load. Feed the readings back into the sizing worksheet and adjust the thresholds if needed. Done means a headroom reading from the test cluster that shows disk and heap within the limits the operations team set, with the test report attached to the layout decision record.

What drives indexer effort and storage cost up, and how to hold them down

This table lists the main drivers of Wazuh indexer storage and sizing effort, how each one raises cost, and a practical way to hold it down. Read each row as a decision point to settle before the sizing is quoted. The main takeaway is that tuning rules, separating evidence retention from operational search, and limiting replicas usually change the bill more than adding hardware.

Driver	How it raises effort or cost	How to hold it down
Endpoints and agents	More agents produce more alerts, inventory data and state events for the indexer to store and search, so disk and node count grow with the fleet.	Confirm the agent count and growth plan in writing, and size from measured alert volume after a pilot rather than from agent count alone.
Log sources and volume	Each firewall, cloud service or application sent by syslog or API adds events, and noisy sources can dominate disk use.	Filter or drop low-value events at the agent or server before indexing, and onboard high-volume sources in phases so the sizing can be checked.
Rule tuning state	Default or untuned rules fire on benign activity, which multiplies alerts stored and reviewed by staff.	Tune noisy rules and alert levels before sizing, so the storage estimate reflects the alerts you will keep rather than the alerts you have today.
Alert retention length	Every extra day of hot retention adds indexed data that must stay searchable on fast disk and in replicas.	Set a short hot retention for operational search and move older data to a lower-cost archive, sized to the actual retention rule.
Compliance evidence scope	Frameworks such as PCI DSS, HIPAA or NIST 800-53 may require longer or provable retention of specific logs, which applies to more data than the security team searches daily.	Identify which log types the assessor needs and keep only those for the full retention period, separating evidence storage from general operational search.
Number of environments	Test, production and disaster recovery copies each need their own indexer capacity, and DR replication duplicates production data.	Size test environments smaller with sampled data, and agree in the scope whether DR holds a full copy, a reduced copy or a restored archive.
Integrations querying the indexer	Dashboards, reports, external tools and scheduled queries add search load, which can require more nodes or memory than storage alone suggests.	Inventory each integration and its query pattern, and move bulk exports or recurring reports to scheduled jobs or the archive where possible.
Replicas and shards	Replica copies multiply stored data and resource use, and poorly planned shard counts add overhead on every node.	Limit replicas for non-critical or archived indices and review shard sizing with the indexer version you deploy.
Cost components	Hardware or cloud storage, staff time for sizing and tuning, archive storage and ongoing operations each carry a separate cost. Hardware is largely one-time or periodic, while archive storage, staff time and operations recur.	Ask for the effort in a written quote tied to the agreed scope, with each component listed separately, and confirm what is one-time and what recurs.

How the indexer layout changes by deployment model

A single-node or all-in-one build places the indexer, server and dashboard on one host, which Wazuh documents as an all-in-one installation. Sizing here is about proving ingestion, parsing and dashboard behavior, not long-term retention. The archive sits on the same data volume as live indices, so retention pressure shares disk space with the operating system and everything else on the host.

Archive location: Aged indices remain on the host's only data volume, so a retention test must watch that volume directly.
Backups: Snapshots usually land in a directory on the same host or an attached disk. This protects against configuration mistakes but does not cover loss of the host itself.
Packages and updates: The host pulls packages from the internet or an internal mirror. Test each patch on a copy before applying it in place.
Event volume: A few test agents rarely reflect production event rates, so do not extrapolate retention figures from a test run.

Confirm with the platform team whether this host will ever be promoted, because a test build rarely carries the layout, backup scope or change control that a production cluster needs.

Protecting stored alert data while it is retained

Retained alerts are a record of your environment, so they need the same protection as the systems that produce them. The controls below cover who can reach the indexer and its data, how components authenticate, how snapshots and archives are kept, and how retention rules are changed. Full host and service hardening is covered in the separate Wazuh security hardening topic.

Access control on the indexer and dashboard

Long retention means old alerts remain searchable for months or years, so a dashboard account that could read last week's alerts may also read last year's. Define which roles can query historical indices, export results, and view data from specific agent groups. Confirm with your identity configuration whether read-only and administrator roles are separated in both the indexer and the dashboard, and review the role list on a fixed schedule.

Certificates between components

Alert data moves from agents to the Wazuh server, from the server to the indexer, and from the indexer to the dashboard. Each hop should use TLS with certificates issued from a CA you control, so that stored data is not accepted from an unverified source. Check the certificate lifetimes and renewal process before go-live, since an expired certificate can stop ingestion or dashboard access without warning.

Encryption of data at rest

Indexed alerts sit on disks that hold years of security telemetry, which may include usernames, IP addresses, command lines and file paths. Ask your storage team whether volumes holding indexer data are encrypted at the disk or filesystem level, who holds the keys, and how keys are rotated. Confirm that the encryption design also applies to temporary and replica storage that the indexer creates during rebalancing.

Snapshot and archive protection

Snapshots and archives copy retained alerts out of the live cluster, so they often outlive the access rules that protected the original index. Store snapshot repositories on a location with its own access policy, encrypt the copies, and restrict who may restore a snapshot into a live cluster. Test a restore on a separate host so you know the archive is readable before it is needed for an investigation or an audit request.

Who may change retention or delete indices

Retention settings and index deletion are the most consequential actions in the stack, because a single change can remove evidence that a regulator or incident responder needs. Limit deletion and retention changes to a small named group, separate them from routine dashboard use, and require a second approver for changes that shorten retention. Verify that these permissions are enforced in the indexer security configuration, not only by team convention.

Audit logging of retention changes

An audit trail should record who changed a retention policy, deleted an index, or altered a snapshot schedule, with timestamps and the previous and new values. Without it, a gap in alerts later may be impossible to explain. Confirm that audit logging is enabled on the indexer, decide where those logs are shipped, and make sure they are kept under retention rules that are at least as long as the alert data they describe.

Retention rules as a managed control

Retention periods are often written into compliance commitments, so a change to them is a change to a control, not a tuning exercise. Keep retention policies in version-controlled configuration, record the reason for each period, and route changes through the same review you use for security configuration. Ask your compliance lead to confirm which retention periods are set by regulation or contract and which are internal choices, because the review path differs for each.

How to prove retention and capacity work before go-live

Before a Wazuh indexer goes live, the sizing and retention design needs evidence that it holds under load, expires data on schedule, restores cleanly and fails in a predictable way. Write the acceptance criteria before the first test runs, so the result is a pass or fail against numbers agreed in advance rather than a judgment made after the fact. Each criterion should name the measured input it depends on, the observable output, and the person who signs off. Without that written baseline, a passing test proves little and a failing one invites debate about what was meant to pass.

The first test is a sustained load test. Use the event rate measured during the baseline period, not the rate assumed in the original estimate, and run it for long enough to cover at least one full rollover cycle and one retention deletion. Watch indexing latency, the indexer heap and disk usage on each node, and whether alerts appear in the dashboard within the delay your SOC accepts. Repeat the run with a peak rate above the baseline to see how much headroom the cluster really has. Ask your partner or vendor to show the exact measurement method for each figure.

Next, verify that index rollover and deletion follow the configured schedule. Confirm from the index management state, not from the dashboard alone, that new indices are created at the expected points and that indices older than the retention period are removed. Check that deletion does not remove an index still inside a legal or contractual hold. Then run a restore test from the archive: pick a sample of indices across several dates, restore them to a separate test cluster, and confirm that documents are readable, field mappings are intact and document counts match the source. Record the counts and the checksums of the archive copies so the comparison is repeatable.

Then test node loss on a clustered indexer. Stop one data node during the sustained load and confirm that the cluster reaches a healthy state again, that replica shards are promoted or rebuilt, and that no alert data is lost or duplicated beyond what your design explicitly accepts. Repeat the test with a node that holds primary shards for active indices. Also check the dashboard during deletion and rollover: run a deletion and a rollover while a set of analysts runs typical searches, and record whether response times stay within the limit you wrote down. A dashboard that stalls during housekeeping is a design problem, not an operator problem.

Finally, test the failure case deliberately. Fill disk on a test node to the configured watermark and observe what the indexer does: whether it stops allocating new shards, whether writes are blocked, and whether the Wazuh server queues or drops events. Confirm that alerting fires before the point where data loss begins, and that the on-call team has a written response: who acts, how they free space or add capacity, and how they confirm recovery. Do not move to production until that alert has been received and the response has been rehearsed. Confirm each of these details with your implementation partner and against the Wazuh documentation for your exact 4.14 release before you run the tests.

What to monitor, back up and document after go-live

Once the Wazuh indexer is live, its disk, memory and retention behavior change every day. The cards below cover what to watch, how to protect and restore the stored alerts, how to keep pace with 4.14 patch releases, and which records prove the retention design works.

Monitor disk and retention trends

Track disk usage over time rather than a single snapshot, and compare the slope against the growth you assumed in the sizing worksheet. Watch indexer health, JVM heap pressure and ingestion rate against the baseline you recorded at go-live. Confirm that the scheduled retention job runs, deletes or moves the expected indices, and reports errors. A retention job that silently stops will show up first as a full disk.

Schedule snapshots and off-cluster copies

Define a snapshot schedule for the indexer indices that matches your recovery point requirement, and keep at least one copy outside the indexer cluster so a cluster failure does not remove the only backup. Record which indices are included, where snapshots are stored, and who can access them. Confirm the snapshot repository configuration and the exact procedure for your release in the Wazuh documentation before you rely on it.

Run periodic restore tests

A snapshot is only useful if it restores. Schedule restore tests into a separate test cluster or isolated environment, and check that alerts from a chosen time window are searchable after recovery. Record the date, the snapshot used, the time to complete and any errors. Restore tests also reveal whether your archived data remains readable after the indexer version changes.

Check compatibility across 4.14 patches

The 4.14 line receives patch releases roughly every one to two months, and the indexer, server, dashboard and agents must stay compatible with each other. Before applying a patch, read the release notes and the upgrade procedure for your exact release, and confirm snapshot repository and index mapping behavior is unchanged. Plan a sizing review after any large change, such as a new log source, a higher agent count or a retention period change.

Keep a sizing worksheet

Maintain the sizing worksheet as a living record of the inputs used at go-live: events per second, average alert size, replica count, shard layout, heap allocation and disk headroom. Update it when any input changes and note the observed values next to the assumed ones. The worksheet is the first document an engineer opens when disk usage departs from forecast.

Maintain the retention matrix and change log

The retention matrix maps each data type or log source to its legal or policy retention period, hot and warm storage duration, and archive location. Pair it with a change log that records every retention change, its reason, approver and effective date. Auditors reviewing log retention rules will ask for both, along with the archive runbook that explains how to retrieve archived data.

Questions buyers ask before hiring help with indexer sizing

How much does a Wazuh indexer sizing exercise cost?

There is no standard price, because the cost follows from a written scope. The main components are discovery of event sources and agents, measurement of current or pilot event rates, modeling of storage and node counts, retention design, and documentation and review. If a pilot or test environment is needed, you also pay for its infrastructure and your staff time. Sizing is largely one-time work, but it should be repeated when event volume or retention rules change. Costs rise with the number of agents, log sources, environments and retention tiers, and with the number of review cycles. When you ask for a quote, request the deliverables, the assumptions behind the model, the inputs you must supply, what is excluded, and how changes to scope are priced.

How long does Wazuh indexer sizing take to complete?

The duration depends on three things: how quickly you can provide a baseline of event data, how many environments are in scope, and how long your sign-off process takes. A single environment with clean historical data moves faster than several environments that need new measurements or a pilot. Compliance and change approval often take longer than the technical work, so identify those reviewers at the start. Ask for a timeline in the quote tied to named milestones, such as inventory complete, baseline accepted, sizing model reviewed and retention policy approved, so you can see which dependencies are on your side.

What do you need from our team for an indexer sizing project?

The work needs four things from your side. First, an inventory of endpoints, servers, network devices and other log sources, with rough agent counts. Second, pilot or historical event data that shows volume per source per day, so the sizing is based on measurements rather than estimates. Third, retention rules in writing from the compliance or legal owner, including how long alerts must be searchable, how long they must be archived, and any legal hold requirements. Fourth, access to the environments, named technical contacts and approved change windows. A named person who can approve the final sizing and retention policy also prevents delays.

Can our internal team size and set retention for the Wazuh indexer?

Yes. An internal team can complete the sizing and retention work by following the sizing and verification steps in this page. The team needs Linux administration skills, basic capacity planning for disk and memory, familiarity with how Wazuh components store and search alerts, and the ability to measure event rates over a representative period. Someone must also translate compliance requirements into index lifecycle settings and archive procedures. Verification is the step teams most often skip: measure disk growth after a retention change, test that archives can be restored, and confirm that searches over the retained period behave as expected before you rely on the design.

Does DeployOpen issue a compliance certification for our log retention?

No. DeployOpen does not issue audit reports, attestations or certifications. DeployOpen prepares the retention configuration, documented retention policies, control descriptions and evidence that your assessment will need. Independent auditors or certification bodies review that evidence and issue any attestation or certification. Before the work starts, ask your auditor which records they expect to see, such as configuration exports, retention settings, access logs and restore test results, so the evidence is collected in the form they will accept.

What retention period should we configure for Wazuh alerts?

No single period is correct for every organization. The period comes from your regulatory obligations, contractual commitments and internal records policy, and it should be decided by the compliance or legal owner in writing. Many teams separate data into a searchable window for daily investigation and a longer archive for audit or legal needs, and the two tiers have different storage costs and access procedures. Ask the owner to specify each data class, its minimum period, its location and who may retrieve it. Then size the indexer for the searchable tier and plan archives for the rest.

What usually makes Wazuh indexer storage grow faster than expected?

Storage growth usually comes from a small number of causes. Noisy rules generate alerts that no one reviews, verbose log sources send fields that are never searched, and duplicate sources are onboarded through more than one path. New agents and environments add volume, and retention periods set for the strictest class often apply to everything. Illustrative example: a team enables a broad file monitoring policy on busy servers, and disk use climbs weeks later. Measure growth per source and per rule, review the top contributors each month, and tune before you add nodes.

How DeployOpen scopes, builds and hands over indexer sizing work

DeployOpen treats indexer sizing and retention as a written, fixed-scope piece of work inside your own infrastructure. The sizing model, retention policy and archive plan are agreed with your compliance and platform owners before anything is built, then tested against your real event volumes.

How we scope

Inventory the agents, log sources and event rates that will feed the Wazuh indexer and record the assumptions behind them.
Capture retention obligations per data class, including the period, the system of record and who approves changes.
Agree in writing which deliverables are covered: sizing model, node layout, index lifecycle rules and archive procedure.

How we build

Build the node and storage layout from the agreed model, documenting disk, memory and shard assumptions for each indexer node.
Configure index lifecycle rules that move data through hot, warm and delete stages according to the approved retention policy.
Test the policy with representative event volumes and verify that storage growth matches the model before go-live.

How we hand over

Deliver a sizing workbook, retention matrix and runbook that your platform team can read without DeployOpen present.
Walk your operators through capacity monitoring, disk alert thresholds and the steps for changing retention safely.
Document the archive plan, including where archived data lives, how it is restored and who is responsible for it.

How we support

Re-run the sizing model when agent counts, log sources or event rates change materially, and record the revised assumptions.
Review retention settings after Wazuh upgrades on the 4.14 line, since indexer behavior should be confirmed on each release.
Ongoing support, upgrades and testing are available as a retainer, so capacity reviews can continue after handover.