Can anyone clarify the expected latency window for sip_trunk_failover_events to appear in the telephony_metrics dashboard after a carrier timeout? We are managing 15 BYOC trunks across APAC regions, and recently noticed a 45-second delay between a SIP 408 Request Timeout on our primary carrier and the corresponding event logging in Genesys Cloud. The environment uses architect_flow_id: af_9928374 with strict failover logic set to immediate on trunk group tg_byoc_apac_01. When querying the trunk metrics via the SDK v3.5.2, the total_failovers count remains zero for nearly a minute post-event, despite the call successfully routing to the secondary trunk. This lag impacts our real-time carrier performance SLA reporting, which relies on accurate carrier_health_score calculations. Is this a known synchronization delay with the SIP registration state refresh, or should we be checking the routing decision timestamp directly through the flow configuration? The carrier logs confirm the timeout at 14:02:15 SGT, but Genesys only reflects the state change at 14:03:00 SGT.
1 Like