Architect flow timeout causing metric skew in performance dashboard

stuck on reconciling architect flow execution timeouts with the agent performance dashboard metrics. we are running a complex flow for claims intake in the eu-fr environment. the flow involves multiple knowledge article lookups and external api calls. recently, we noticed a discrepancy where the dashboard reports significantly higher handle times than what is logged in the conversation detail views. specifically, the ‘talk time’ metric appears inflated by approximately 45 seconds per interaction. this aligns with the timeout threshold configured for our external integration nodes.

the issue seems to stem from how the platform categorizes these timeout events. when a node times out, the agent is placed on a temporary hold while the system retries or fails over. however, the performance dashboard continues to accumulate talk time during this interval, even though no voice activity is occurring. this is creating a false narrative regarding agent efficiency. our sla calculations are being negatively impacted because the effective talk time is higher than the actual customer engagement time.

we have verified that the conversation detail view correctly logs the ‘hold’ state during these timeouts, but the aggregate performance views do not seem to exclude this duration from the talk time calculation. is there a specific metric or filter available in the performance dashboard that can exclude time spent in ‘system hold’ due to flow timeouts? alternatively, is this a known limitation in the eu-fr data residency environment regarding metric aggregation? we need to ensure that our agent performance reviews are based on accurate engagement metrics rather than technical latency artifacts. any guidance on configuring the dashboard to reflect true agent-customer interaction time would be appreciated.

I’d recommend looking at at the SIP session timer settings in your BYOC trunk configuration, as expired registrations during those external API calls can artificially inflate talk time metrics. Try adjusting the re-INVITE interval to prevent mid-call drops.

{
 "sip_settings": {
 "session_timer": {
 "enabled": true,
 "interval_seconds": 120,
 "refresh_method": "UPDATE"
 }
 }
}

resource "genesyscloud_architect_flow" "claims" {
 flow_timeout_ms = 30000
}

SIP timers are irrelevant here. The discrepancy stems from the flow timeout configuration. If the flow hangs on external API calls, the dashboard counts the wait time as talk time. Adjusting the flow timeout in Terraform resolves the metric skew.

How I usually solve this is by checking the bulk export metadata for those specific timestamps.

The dashboard aggregation often lags behind the raw conversation logs in EU-FR due to asynchronous processing for legal compliance. Verify the privacy_compliance_enabled flag in your state file to ensure the timeout isn’t being masked by retention policies.