Architect flow analytics mismatch in europe/paris

Anyone know why the performance dashboard metrics for a specific queue diverge significantly from the raw conversation detail views when analyzing data within the europe/paris timezone?

the environment is genesys cloud enterprise edition, version 23.10. the issue is isolated to a flow utilizing a script block for compliance verification. the flow architecture involves a data action block that triggers immediately after the script is marked as complete. this data action updates a custom field on the contact object, specifically tracking the ‘compliance_verified’ status.

when viewing the queue analytics summary for the last 24 hours, the average handle time (aht) shows a steady 4m 12s. however, when drilling down into the conversation detail views for the same time window, approximately 15% of the interactions show an aht exceeding 6 minutes. these longer durations correlate directly with calls where the script block experienced a timeout before the data action could execute. the dashboard appears to be aggregating the duration based on the initial queue entry timestamp rather than the actual disposition timestamp, which creates a discrepancy in the reported efficiency metrics.

the business requirement is to have the dashboard reflect the true operational capacity, including the overhead caused by these script timeouts. currently, the variance makes it difficult to justify resource allocation for the support tier. the script itself is configured with a 30-second timeout, but the flow does not log an explicit error code in the standard monitoring views, only a silent failure in the data action payload.

is there a known configuration in the performance views that adjusts how aht is calculated for flows with conditional script blocks? or does the europe/paris region have a specific latency issue with the script engine that is not being accounted for in the standard analytics aggregation? the documentation mentions that script references must adhere to uuid v4 format, which has been verified, but the timing discrepancy persists regardless of the script content.