The Alerts Overflow mechanism was designed to prevent system overflow and improve 'noise reduction', when lots of alerts from the same environment, product and rule are occurring in a short period of time. For example, making sure repetitive attacks such as brute force or DDoS don’t flood the platform and DB and the SOC can continue functioning as it should.

There are two different configurations for the Overflow. 

The initial overflow configuration is hard coded in the Database and defines that once more than 50 similar alerts are ingested within a 10 minute timeframe - the Overflow mechanism is triggered. This is determined by the Is_Overflow method which is configured in the connector side (added to the connector code in the IDE) and which triggers the overflow mechanism with this default configuration.
Once triggered, an Overflow case will be added to the case queue, with one alert indicating the environment, product and rule of the overflowing alert, and an Overflow tag.

The second overflow configuration defines what happens AFTER the Overflow mechanism is triggered. This can be defined in the Settings >  Advanced > Alerts Grouping > Overflow section. 

  • Timeframe for Overflow Case grouping (in hours): Choose the number of  hours in which to group the overflow alerts for the Case. Note that is only applied to rules which are grouped by entities only. 
  • Max. alerts grouped into an Overflow Case: Define the maximum number of overflow alerts to group together into one Case.  

Let's explain this with an example using the values given in the screenshot.


50 Phishing Alerts are ingested within 8 minutes. The 51st alert is then shunted off into an Overflow case. 

Over the next three hours another 119 phishing alerts are ingested. This means that four overflow cases are created. Each case containing 30 Alerts. Once the three hours are up, we go back to default status.