Multiple integrations not running in parallel (only one executes at a time)

[kushagra varshney]

Hello team,

I am facing an issue with Wazuh integrations execution order.
I currently have 3 external integrations configured:

• IRIS

• AbuseIPDB

• MISP

The problem is that when alerts are generated, only one integration executes at a time.
Sometimes IRIS does not execute at all if other integrations (for example MISP) are already running or busy processing events.

Use case example:
I get around ~1000 alerts in 2 minutes. MISP runs first, then AbuseIPDB, but IRIS never gets triggered in many cases. It looks like integrations are not running concurrently and if one integration is slow or overloaded, the others get blocked.

Questions:

1. Is this the expected behaviour that integrations are executed sequentially and not parallel?

2. Is there any configuration available to allow integration parallel execution or queueing?

3. If not available today, is this a planned feature or improvement? It becomes a major limitation in high volume environments where multiple enrichment sources are needed.

4. Any recommended workaround to ensure all integrations get a chance to run reliably?

5. Is there any rate limit issues on incoming and outgoing traffics? if there is then how to solve it.

Thanks,
Kushagra

[musbau....@wazuh.com]

Hi,

This is a known limitation as Wazuh runs integrations sequentially, not in parallel. So if MISP is slow or backed up, IRIS or AbuseIPDB might never get triggered, especially during alert bursts.

There’s no built-in way to run them concurrently, and under high load, integrations can time out or get skipped.

You can offload enrichment to a SOAR like Shuffle as Wazuh recently made a partnership with them and send Wazuh alerts there and run your IRIS/MISP/AbuseIPDB lookups in parallel with proper error handling.

Also, double-check rate limits on those external APIs—they can silently stall your scripts.

Hope that helps!

You can use the documentation below for reference.

https://wazuh.com/blog/integrating-wazuh-with-shuffle/

https://community.tguard.org/t/iris-does-not-receive-alerts-from-wazuh/30

Regards,

[kushagra varshney]

Hi,

Lets say if I just put MISP and abuseipdb on Wazuh and iris on shuffle will it be able to match the all 20lakh alerts that come in 12-13hrs with MISP without dropping any alert.

Regards,
Kushagra 

[musbau....@wazuh.com]

Hi,

Handling over 2 million alerts over 12–13 hours (roughly 40–50 alerts/second) is pushing the limits of Wazuh’s native integrations even with just MISP and AbuseIPDB. The execd daemon that runs these scripts has a default cap of 128 executions per second, but in practice, slow API calls, timeouts, or rate limits can easily cause enrichments to be dropped.

regards, 

[kushagra varshney]

Hi,

I am facing a new issue with just MISP there now my integration is stuck on enriching 2 days before alerts the today ones are not even in the list of being matched. What could be the possible issue the buffer caused due to 20lakh alerts if not then how to solve it.

Thanks,
Kushagra

[musbau....@wazuh.com]

Hi,

Wazuh processes integrations in the order alerts are received, and the execd daemon has a hard internal queue (default max ~128 pending executions). When you have sustained high throughput (like 40–50 alerts/sec) and slow MISP lookups , execd falls behind. It keeps trying to process older alerts first, so new alerts never get enriched they either wait indefinitely or get dropped silently once the internal buffers fill.

This isn’t a “buffer” in the filesystem it’s an in-memory execution queue inside the ossec-execd process. Once overwhelmed, it doesn’t skip old alerts; it just lags further and further behind.

You can check logs to see if you can find anything that can help

grep "execd" /var/ossec/logs/ossec.log
Look for messages like:

"Maximum number of integrations per second reached"
"Too many pending active responses"
"Repeated execution attempts on old timestamps"

Regards,

[kushagra varshney]

Hi,

Will using shuffle between MISP and Wazuh make any changes means first all allowed traffic events goes to shuffle or automated using shuffle for matching because I have a doubt  if Wazuh daemon falls on sending making api calls with MISP, it might fall with shuffle to so is really a solution to it or not.