Google Workspace Alert Center Ingestion Delay: Why Security Alerts Arrive Hours Late in Your SIEM
Reach 50,000+ security professionals
Sponsor a newsletter slot and put your brand in front of CISOs, engineers, and IT decision-makers.
Google Workspace Alert Center does not deliver alerts in real time. When a suspicious sign-in occurs, Google's backend pipeline analyzes the sign-in signals, determines whether the activity crosses the threshold for an alert, and creates the alert -- this analysis takes time, commonly 1-6 hours. The resulting alert in the SIEM then has a createTime that is hours after the event it describes. The event itself is recorded in Admin SDK audit logs (Login audit log) with a near-real-time timestamp. For SIEM platforms evaluating Google Workspace as a log source alongside other identity providers, see this Microsoft Sentinel vs IBM QRadar SIEM comparison.
Understanding the Three Timestamps in an Alert Center Alert
An Alert Center alert has three time fields that mean different things:
createTime: When the Alert Center service created the alert record. This is the time you will see in SIEM if the connector indexes by createTime. It is hours after the actual event.
startTime: The beginning of the period the alert covers. For a suspicious login alert, this is when the suspicious login occurred. For a phishing email alert, this is when the email was received. This is the correct timestamp for correlating the alert with other evidence from the same event window.
endTime: The end of the period covered by the alert. For a single-event alert (one suspicious sign-in), startTime and endTime are the same. For aggregate alerts (a burst of admin role changes over 30 minutes), startTime and endTime bracket the event window.
When building an incident timeline, always use startTime (and endTime if the alert covers a range) for the event's position in the timeline. createTime tells you when Google noticed, not when the event happened.
SIEM connectors that index Alert Center alerts by createTime will show the alert appearing hours after the event. Connectors that re-index by startTime will show it in the right position in the timeline but may require the SIEM's time parsing to be configured for the correct field.
Why Alert Center Alerts Are Inherently Delayed
Alert Center alerts are not generated by real-time rule evaluation. Google's backend applies machine learning models and risk scoring to sign-in events, email flows, and admin actions. These models run on batch pipelines rather than stream processors for most alert types. The delay between event and alert creation reflects the pipeline processing time, not a system failure.
Specific alert types and their typical latencies:
Suspicious sign-in alerts: 1-6 hours. The sign-in is logged immediately in the Login audit log, but the Alert Center alert is created after the risk scoring pipeline processes the sign-in against the user's historical pattern.
Government-backed attack alerts: hours to a day. These alerts represent Google's threat intelligence assessments and are generated manually with additional review.
Google Voice phishing alerts: minutes to hours depending on the volume of similar phishing being processed at the time.
Gmail phishing delivery alerts: typically 30-120 minutes, as Gmail's safe browsing and phishing detection scans incoming email but Alert Center creation follows after classification.
Admin activity alerts (new admin, compromised admin): typically 15-60 minutes.
None of these delays can be reduced by changing the SIEM polling interval -- the delay is in Alert Center's pipeline, not in the SIEM's collection. Shortening the polling interval reduces the SIEM-side lag (the time between alert creation and SIEM ingestion) but cannot recover the pipeline latency between the event and alert creation.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Reducing SIEM-Side Ingestion Lag
While Alert Center pipeline latency is fixed, the SIEM-side lag (time between alert creation and SIEM ingestion) is configurable:
Shorten the SIEM connector polling interval. Most SIEM connectors for Google Workspace have a configurable polling interval. Reducing from the default (often 30-60 minutes) to 5-10 minutes reduces the SIEM-side lag component. For the Alert Center API, the minimum safe polling interval is 5 minutes -- polling more frequently than once per 5 minutes may trigger API rate limits.
Use push notifications instead of polling. The Alert Center API supports Pub/Sub push notifications via Google Cloud Pub/Sub. When a new alert is created, Pub/Sub delivers a notification to a subscriber within seconds. SIEMs with Pub/Sub connectors can receive Alert Center alerts within seconds of their creation rather than waiting for the next poll cycle. This eliminates SIEM-side lag but does not change the underlying alert creation latency.
Use the Admin SDK Audit Log alongside Alert Center. For suspicious sign-ins, the Login audit log event (via the Admin SDK Reports API) is generated within minutes of the sign-in. Configure your SIEM to ingest both the Login audit log and Alert Center. The Login audit log provides near-real-time visibility into the sign-in event; the Alert Center alert provides Google's risk assessment of that sign-in. Correlate them by the user identifier and time window rather than waiting for the alert to arrive.
Building an Accurate Incident Timeline from Workspace Data
Because Alert Center delays are inherent, an accurate incident timeline for a Google Workspace incident requires combining multiple data sources:
Layer 1: Admin SDK Audit Logs (near-real-time)
- Login audit log: sign-in events, failed sign-ins, sign-in location and IP
- Admin audit log: admin role changes, delegation changes, app permissions
- Drive audit log: file access, sharing, download events
Layer 2: Gmail Log Export (minutes delay) For email-based incidents, Gmail Log Export provides delivery, receipt, and routing events with timestamps close to the actual event.
Layer 3: Alert Center API (hours delay) Alert Center provides Google's risk assessment, the specific alert type (suspicious sign-in, phishing, government-backed attack), and links to affected users and assets. Use createTime to filter during SIEM queries but use startTime for the event position in the timeline.
Practical example: a suspicious sign-in at 09:00 will appear in the Login audit log at approximately 09:02 and in the Alert Center at approximately 12:00-15:00. If you investigate at 10:00, the Login audit log has the event but Alert Center does not yet. If you investigate at 14:00, both are available. Build dashboards that query both sources and join on user identifier and time window to avoid gaps in coverage.
Common Diagnostic Mistakes
Mistake: concluding a SIEM integration is broken because Alert Center events are late. Alert Center latency is expected. Before concluding an integration is broken, compare the SIEM-visible createTime with the alert's actual createTime via a direct API query:
curl -X GET \
'https://alertcenter.googleapis.com/v1beta1/alerts' \
-H 'Authorization: Bearer <access-token>'
If the API returns recent alerts that are not yet in the SIEM, the SIEM connector polling interval is the issue. If the API returns no recent alerts and you expected them (based on a sign-in you can see in the Login audit log), Alert Center pipeline latency is the issue -- not a SIEM misconfiguration.
Mistake: treating Alert Center as the primary event source. Alert Center is a risk assessment output, not a raw event source. Use the Admin SDK Audit Log as the primary source for event timestamps and details; use Alert Center for risk signal enrichment.
Mistake: using createTime for incident timeline correlation. Building an incident timeline that places the alert at createTime makes the suspicious sign-in appear to have occurred 3-6 hours after it actually did. Always extract startTime from the alert and use it as the event timestamp.
When to Investigate a Genuine Integration Problem
An actual Alert Center integration failure (not expected latency) looks different:
- Alerts visible in the Google Workspace Admin Console under Security > Alert Center are not appearing in the SIEM even after a 24-hour wait.
- The SIEM connector is returning errors when querying the Alert Center API.
- The number of alerts in Alert Center has increased (visible in the Admin Console) but SIEM event counts for the same source have not changed.
For these scenarios:
- Verify the service account used by the SIEM connector has the
Alert Center Viewerrole in the Google Workspace Admin Console. - Check the OAuth scopes authorized for the connector include
https://www.googleapis.com/auth/apps.alerts. - Verify the connector's API credentials have not expired (service account key rotation or OAuth token expiry).
- Check the Alert Center API for quota errors if the SIEM polling is configured below the 5-minute minimum.
The bottom line
Google Workspace Alert Center alerts arrive hours after the events they describe because Alert Center is a risk-scoring pipeline, not a real-time event stream. The delay is in Google's backend, not in your SIEM integration. Build incident timelines using the alert's startTime field (the actual event time) rather than createTime (when Google finished scoring it). Supplement Alert Center with the Admin SDK Login audit log -- available within minutes of the event -- to get near-real-time visibility during active incidents, and treat Alert Center as risk enrichment that arrives later. For identity platform context across your SIEM data sources, see this browser-layer identity security guide.
Frequently asked questions
Why are Google Workspace Alert Center alerts showing up hours late in my SIEM?
Alert Center alerts arrive hours late because Google's alert generation pipeline is not real-time. When a suspicious sign-in or phishing event occurs, Google's backend scoring models analyze the event against historical patterns, risk signals, and threat intelligence before creating an Alert Center record. This analysis takes 1-6 hours depending on the alert type. The delay is in Google's pipeline and cannot be reduced by changing your SIEM's polling interval. What can be reduced is the additional lag from SIEM polling -- shortening the polling interval from 30 minutes to 5-10 minutes gets alerts into the SIEM faster after Google creates them, but cannot recover the pipeline latency.
What is the difference between createTime and startTime in Google Workspace Alert Center?
createTime is when Google's Alert Center pipeline finished processing the event and created the alert record -- this is hours after the actual security event. startTime is when the triggering event actually occurred: for a suspicious sign-in alert, startTime is the time of the sign-in; for a phishing alert, it is when the email was received. When building an incident timeline, always use startTime as the event timestamp. Using createTime incorrectly places the event hours later than it actually happened, which distorts the incident timeline and can lead to incorrect sequencing of events.
How do I get Google Workspace security alerts in my SIEM faster?
For the SIEM-side lag (time between alert creation and SIEM ingestion), shorten the SIEM connector polling interval to 5-10 minutes, or configure Google Cloud Pub/Sub push notifications if your SIEM connector supports them -- Pub/Sub delivers alerts within seconds of creation. For the underlying pipeline latency (time between the event and alert creation), use the Admin SDK Login audit log and Admin audit log alongside Alert Center. These audit logs are generated within minutes of the event and provide near-real-time visibility into sign-ins, admin actions, and email events that Alert Center will only score and alert on hours later.
Is it normal for Google Workspace suspicious sign-in alerts to come hours after the sign-in?
Yes. Google Workspace suspicious sign-in alerts are generated by a risk-scoring pipeline that evaluates the sign-in against the user's behavioral history, location patterns, device fingerprints, and threat intelligence feeds. This pipeline runs in batch mode and typically produces alerts 1-6 hours after the actual sign-in. The sign-in itself is logged immediately in the Login audit log, available via the Admin SDK Reports API within minutes. If you need near-real-time detection of suspicious sign-ins, ingest the Login audit log rather than relying on Alert Center for the initial detection.
How do I build a Google Workspace incident timeline when Alert Center alerts are delayed?
Use a layered approach: ingest the Admin SDK Login audit log for sign-in events (near-real-time), the Admin audit log for admin actions (near-real-time), and Gmail Log Export for email events (minutes delay). These provide the event timestamps you need for the incident timeline. Use Alert Center as an enrichment layer that provides Google's risk assessment and additional context, keyed by user identifier and the alert's startTime field. Join the audit log events and Alert Center alerts on user and time window in your SIEM to build a complete picture that is accurate even before the Alert Center alerts arrive.
How do I tell if my Google Workspace SIEM integration is broken versus just delayed?
Query the Alert Center API directly using the Admin SDK and compare the results to what appears in your SIEM. If the API returns recent alerts that are not yet in the SIEM and the gap is under 60 minutes, the SIEM polling interval is adding lag but the integration is functioning. If alerts are visible in the Google Workspace Admin Console under Security > Alert Center but do not appear in the SIEM after 24 hours, the integration is likely broken: check that the service account has the Alert Center Viewer role, verify the OAuth scope includes apps.alerts, and check the SIEM connector logs for API authentication errors.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Daily briefings + Google Top Stories in one step.
Enter your email and we'll subscribe you to the daily briefing and add Decryption Digest to your Google Search feed at the same time.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.