Does anyone know if there is a known latency or ingestion delay in the Security Audit logs when a BYOC trunk triggers an automatic failover? We are managing 15 trunks across APAC regions, primarily Singapore and Jakarta, and have noticed discrepancies in the timestamp accuracy of security events recorded during high-volume failover events.
Specifically, when a primary carrier drops below the quality threshold defined in our routing strategy, the system correctly routes traffic to the secondary carrier. However, the subsequent audit events-specifically the TRUNK_STATUS_CHANGE and OUTBOUND_CALL_ATTEMPT-appear in the Compliance dashboard with timestamps that are up to 45 seconds behind the actual SIP signaling events captured in our PCAPs. This gap creates a significant issue for our forensic analysis during compliance audits, as we cannot definitively correlate the exact moment of carrier switch with the authentication challenges issued by the new carrier.
We are currently using the Genesys Cloud Analytics API v2 to pull these logs, specifically querying /api/v2/analytics/security/events. The response payload looks standard, but the temporal alignment is off.
“Audit logs are generated in near real-time, with a maximum propagation delay of 30 seconds under normal load conditions. During high-traffic periods or system maintenance, delays may extend up to 60 seconds.”
The documentation suggests a 30-second max, yet we are seeing consistent 45+ second delays specifically tied to the failover logic execution. We have verified that our NTP settings on the hybrid workers are synchronized correctly, so the issue likely lies within the cloud processing pipeline for security events during state transitions. Has anyone encountered similar timestamp drifts in the security audit trail during active failover scenarios, or is there a specific flag or endpoint that provides more granular, real-time signaling logs for compliance purposes? We need to ensure our audit trail is forensically sound for our financial services clients.