The alert overflow mechanism is designed to prevent system overflow and
improve noise reduction when large volumes of alerts from the same
environment, product, and rule are occurring in a short period of time. This
mechanism helps avoid repetitive attacks, such as brute force or DDoS, from flooding the
platform and database, while ensuring that the Security Operations Center (SOC) continues
to function as planned.
The alert grouping mechanism works to intelligently group alerts into
cases based on mutual entities and time proximity, allowing analysts to
perform contextual analysis of multiple alerts in one case.
In these cases, you'll see multiple alerts in one case, and mutual entities
marked in the entities list and the Explorer page.
There are two different configurations for the overflow:
Initial overflow configuration
This 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 on the connector side
(added to the connector code in the IDE).
Once triggered, an overflow case is added to the case queue, with one alert
indicating the environment, product, and rule of the overflowing alert,
with an overflow tag.
Second overflow configuration
This configuration defines what happens after the overflow mechanism
is triggered. This can be defined in SOAR Settings
> Advanced > Alerts Grouping in the Overflow
section.
Timeframe for Overflow Case grouping (in hours): Choose the number of
hours in which to group the overflow alerts for the case. This 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.
For example, 50 phishing alerts are ingested within 8 minutes. The 51st alert
triggers the overflow mechanism, and an overflow case is created.
Over the next three hours another 119 phishing alerts are ingested resulting
in four overflow cases, each containing 30 alerts. Once the
three hours are up, the system returns to the default configuration.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 UTC."],[[["\u003cp\u003eThe alert overflow mechanism prevents system overload and reduces noise from high volumes of similar alerts, ensuring the Security Operations Center (SOC) functions effectively during events like brute force or DDoS attacks.\u003c/p\u003e\n"],["\u003cp\u003eThe initial overflow configuration triggers when more than 50 similar alerts are ingested within 10 minutes, creating an overflow case with one representative alert.\u003c/p\u003e\n"],["\u003cp\u003eA second overflow configuration in SOAR Settings > Advanced > Alerts Grouping allows customization of how overflow alerts are grouped into cases after the initial trigger.\u003c/p\u003e\n"],["\u003cp\u003eCustomizable parameters for the overflow configuration include setting the timeframe for grouping overflow alerts and defining the maximum number of alerts per overflow case.\u003c/p\u003e\n"]]],[],null,["# Configure alert overflow\n========================\n\nSupported in: \nGoogle secops [SOAR](/chronicle/docs/secops/google-secops-soar-toc) \n| **Note:** This guide is for administrators configuring the alert overflow mechanism to manage alerts and maintain system performance.\n\n\nThe alert overflow mechanism is designed to prevent system overflow and\nimprove *noise reduction* when large volumes of alerts from the same\nenvironment, product, and rule are occurring in a short period of time. This\nmechanism helps avoid repetitive attacks, such as brute force or DDoS, from flooding the\nplatform and database, while ensuring that the Security Operations Center (SOC) continues\nto function as planned.\n\n\nThe alert grouping mechanism works to intelligently group alerts into\ncases based on mutual entities and time proximity, allowing analysts to\nperform contextual analysis of multiple alerts in one case. \n\nIn these cases, you'll see multiple alerts in one case, and mutual entities\nmarked in the entities list and the **Explorer** page.\n\nThere are two different configurations for the overflow:\n\n**Initial overflow configuration**\n\nThis configuration is hard-coded in the database and defines\nthat once more than 50 similar alerts are ingested within a 10-minute\ntimeframe, the overflow mechanism is triggered. This is determined by the\n`Is_Overflow` method, which is configured on the connector side\n(added to the connector code in the IDE). \n\nOnce triggered, an overflow case is added to the case queue, with one alert\nindicating the environment, product, and rule of the overflowing alert,\nwith an overflow tag.\n\n**Second overflow configuration**\n\nThis configuration defines what happens *after* the overflow mechanism\nis triggered. This can be defined in **SOAR Settings\n\\\u003e Advanced \\\u003e Alerts Grouping** in the **Overflow**\nsection.\n\n- **Timeframe for Overflow Case grouping (in hours):** Choose the number of hours in which to group the overflow alerts for the case. This is only applied to rules which are grouped by entities only.\n- **Max. alerts grouped into an Overflow Case:** Define the maximum number of overflow alerts to group together into one case.\n\n\nFor example, 50 phishing alerts are ingested within 8 minutes. The 51st alert\ntriggers the overflow mechanism, and an overflow case is created.\nOver the next three hours another 119 phishing alerts are ingested resulting\nin four overflow cases, each containing 30 alerts. Once the\nthree hours are up, the system returns to the default configuration.\n\n**Need more help?** [Get answers from Community members and Google SecOps professionals.](https://security.googlecloudcommunity.com/google-security-operations-2)"]]
