Looking for advice on the data integrity of trunk health metrics during rapid failover sequences. We are currently managing 15 BYOC trunks across APAC regions, primarily utilizing Singapore and Tokyo endpoints. When a primary carrier experiences a SIP registration timeout, the failover logic triggers immediately to the secondary carrier. However, the subsequent analytics reports in Performance View show a significant gap in call attempt data during the transition window. The API endpoint /v2/analytics/trunks/realtime returns a 200 OK status, but the call_attempts field is zero for the duration of the swap. This discrepancy makes it difficult to calculate accurate abandon rates for the affected interval. The logs indicate that the calls are being routed successfully post-failover, but the historical aggregation seems to miss the initial burst. We are using the standard SDK version 3.1.4 for our reporting dashboards. Is there a known ingestion delay or a specific flag required to ensure the metrics capture the pre-failover state accurately? How can we reconcile the real-time API data with the historical reports to ensure accurate SLA reporting during carrier swaps?
This happens because the API polling interval mismatch during failover. The platform updates trunk status every 30 seconds, but JMeter captures requests at 1-second intervals.
Sync your test ramp-up with the API refresh cycle. Use a 30-second delay between health checks to align data points. This prevents the gap in your analytics reports.