+4Hi,
I am observing 25-45 mins of delay in SecOps case generation.
I compared this using alert created time and SOAR case created time.
Does anyone know what could be causing this delay issue? This is really critical issue for High and Critical priority incidents.
+1A 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:
Source event time
Google SecOps ingestion time
Detection / alert created time
SOAR alert received time
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.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
