# Identify the Wazuh queue before changing event capacity > Identify whether Wazuh drops involve secure agent communication or an event-specific analysis queue before tuning capacity. Do not apply queue_rd sizing to remote syslog input. - Canonical URL: https://update.dsesecurity.com/updates/identify-the-wazuh-queue-before-changing-event-capacity/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-30T06:47:18+00:00 - Modified: 2026-10-30T06:47:28+00:00 - Last reviewed by DSE: 2026-10-30 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Identify whether Wazuh drops involve secure agent communication or an event-specific analysis queue before tuning capacity. Do not apply queue_rd sizing to remote syslog input. ## Potentially affected Wazuh server operators investigating event drops or queue capacity in the documented communication and analysis stages. ## DSE recommendation DSE recommends matching each proposed queue change to a named input path and measured drop category before tuning it. ## Article Bottom line: Locate the queue and event population before choosing a capacity setting. Keep secure agent input, remote syslog and the analysis event categories explicit in the investigation. ## Source fact: documented behavior The [Queuing mechanisms](https://documentation.wazuh.com/current/user-manual/manager/wazuh-server-queue.html) guide limits queue_rd to agent events with a secure connection and explicitly excludes remote syslog events from that queue setting. The analysis engine separates incoming events into category queues with individually configurable processing threads. Its analysis statistics expose received or dropped events by type, and the guide directs persistent internal-option overrides to local_internal_options.conf to survive upgrades. ## What the source does not establish This article chooses the documented Wazuh queue and observation point. It does not supply a universal queue size, guarantee zero event loss or approve deleting buffered events to make an incident appear resolved. ## Applicability questions - Did the affected events arrive through an agent or remote syslog? - Which daemon and event category show the drop evidence? - What measurements distinguish input congestion from analysis pressure? - Where will a reviewed override be retained across upgrades? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE recommends matching each proposed queue change to a named input path and measured drop category before tuning it. - Choose one actual affected source and document its delivery path into Wazuh. Record the event type and the daemon evidence that identifies the bottleneck. If the source is remote syslog, reject a worksheet that proposes changing the secure-agent queue merely because both kinds of events reach the same server. Keep the input classification visible beside the proposed setting. - Capture a baseline from the supported daemon statistics and identify the specific analysis category if processing drops are involved. Have the server operator propose a bounded adjustment to that category rather than enlarging every queue together. Record the resource allowance and observation interval as deployment decisions; do not borrow the source’s example values as a guaranteed capacity for an unrelated workload. - Place approved persistent overrides in the documented local override location and retain the previous configuration. Change one investigated cause at a time, then repeat the same representative event workload. If a different stage becomes constrained, reopen the diagnosis rather than increasing additional limits without measurements. Preserve pending events through the established recovery process instead of discarding them to reduce a displayed queue. ## Verification and evidence Proposed verification: compare secure-agent and remote-syslog case records, then ask a reviewer to map each to the applicable communication setting before any change. For an approved isolated workload, retain before-and-after daemon statistics, event-category counts and actual delivery observations at the intended destination. Reconcile a smaller queue display with the received and dropped-event evidence; do not accept the display alone as proof of recovery. Record which override file contains the change and how it will be checked after a later upgrade. No event flood, capacity benchmark or queue tuning was performed for this article, and the proposed cases establish no general throughput promise. ## Official references - [Queuing mechanisms](https://documentation.wazuh.com/current/user-manual/manager/wazuh-server-queue.html) — Wazuh; official product documentation. Source review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings. ## Primary reference - Name: Wazuh — Queuing mechanisms - Authority: documentation.wazuh.com - URL: https://documentation.wazuh.com/current/user-manual/manager/wazuh-server-queue.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Identify the Wazuh queue before changing event capacity,” DSE Security, https://update.dsesecurity.com/updates/identify-the-wazuh-queue-before-changing-event-capacity/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.