Dela Case Generation in SOAR

A 25–45 minute delay can come from several different points in the pipeline, so I would first separate alert generation delay from SOAR case creation delay.

The key question is: are you comparing the source alert created time, the Google SecOps alert created time, or the SOAR case created time?

I would validate the timestamps in this order:

1. Source event time

2. Google SecOps ingestion time

3. Detection / alert created time

4. SOAR alert received time

5. SOAR case created time

Possible causes:

• Log ingestion delay before SecOps receives the event

• Detection rule frequency / match window causing delayed alert creation

• Rules using enriched/contextual fields, which can add latency

• Connector/API polling delay from the source system

• Connector backlog, errors, or rate limits

• SOAR ETL/case creation queue latency

• Alert grouping or overflow behavior

• Platform-side issue requiring Google support review

If the delay is between event time and alert created time, I would check ingestion timestamps, rule frequency, match window, and whether the detection depends on enrichment/context fields.

If the delay is between SecOps alert created time and SOAR case created time, I would check connector logs, SOAR ETL/case creation behavior, alert volume, grouping configuration, and whether overflow handling is being triggered.

For High/Critical incidents, I would not rely only on case creation if there is consistent latency. I would add a direct notification path at alert/detection time, then let SOAR case creation happen separately.

while what ​@whathehack81 described is a great starting point to troubleshoot generic end to end delays, it looks like ​@soaruser is referring to specifically the delay between

alert created time and SOAR case created time

The usual integration between Secops SIEM and SOAR is through this connector, being the SOAR who pulls the alerts from Secops SIEM.

If there’s an excessive delay between them, I’d check in

Secops UI > settings > SOAR settings > Connectors > GoogleChronicle > Parameters:

-Run Every: this would be the job execution frequency, double-check if it is too high and if it is the case, reduce it accordingly

Depending on the alert volume, you might want to also check on these:
-Max Hours Backwards
-Max Alerts To Fetch

If those parameters were already optimized, then I’d check with Google support as it might be an issue from Google backend.

hope it helps

Thanks — that helps. I’ll check the GoogleChronicle connector parameters first, especially Run Every, Max Hours Backwards, and Max Alerts To Fetch.

The delay I’m seeing is specifically between alert created time and SOAR case created time, so connector polling/batch limits makes sense as the first place to validate.

Thanks both ​@hliu  and ​@whathehack81 for your inputs.
Here’s the details:
Run Every:  10 sec

Max Hours Backwards: 1
Max Alerts To Fetch: 100
Alert Grouping: Set to No Group for these alerts
No delay in ingestion timestamp and alert creation time. 
Only between SOAR case creation time and alert creation time (Not observing delay for all alerts but 5 out of 10 alerts)
 

I’d suggest try reducing the max alerts to fetch a smaller batch, maybe down to 3-5 alerts each time, to see if it makes a difference. Otherwise, as ​@whathehack81 was mentioning checking the connector logs or reaching out to Google support might be helpful.

Hi ​@soaruser,

How many alerts is being produced every x seconds the connector is trying to pull alerts in from. Is it a case of your pulling 100 alerts every 10 seconds, and there’s more then 100 so it’s continuously playing catch-up and has over-time caused a delay?.

Kind Regards,

Ayman

​@AymanC  has a good insight here and if this is the case -  you’re environment probably needs to have a good tuning.    Everything doesnt need to be a case initially, you can turn that off so it just shows up in the rules dashboard.   Then, once things are tuned, you can turn it back on for alerting.