Stuck on a critical routing issue within our EU-West BYOC environment. The primary SIP trunk connection is experiencing intermittent latency spikes, triggering the failover mechanism in the Architect flow. However, the Performance dashboard continues to report successful call connections with zero abandoned calls during these windows, which contradicts the actual customer experience reports we are receiving from the floor. The Architect flow is configured with a standard ‘Connect to Queue’ block, followed by a ‘Transfer to SIP URI’ block for the primary provider, and a fallback ‘Transfer to SIP URI’ block for the secondary provider. The timeout is set to 30 seconds. When the primary trunk fails, the flow should immediately route to the secondary, yet the dashboard metrics show a ‘Connect’ status with an Average Handle Time (AHT) that matches the timeout duration, suggesting the system believes the call was connected when it was likely dropped or stuck in a silent loop. The specific error seen in the conversation detail view is not a standard SIP 408 or 503, but rather a generic ‘System Error’ at the transfer step. We have verified the SIP trunk health monitors in the Admin console, and they correctly flag the primary trunk as ‘Degraded’ during these incidents. The discrepancy lies between the architectural logic execution and the reported performance metrics. Is there a known latency threshold in the Performance dashboard calculation that ignores SIP-level timeouts? Or is this a configuration error in how the ‘Transfer to SIP URI’ block handles non-200 OK responses from the primary trunk? We need to reconcile these metrics to accurately report uptime and agent efficiency to stakeholders. The environment is Genesys Cloud Standard, using the latest Architect version available in the EU region. Any insights into how the dashboard interprets failed SIP transfers that are caught by the flow logic would be appreciated.