Degraded Warm Transfers Performance

Update timeline

1. investigating May 15, 2026, 03:18 PM UTC

   We are actively investigating an issue related to warm transfers not merging.

2. monitoring May 15, 2026, 04:03 PM UTC

   A root cause has been identified at the network layer, attempting a fix now and monitoring

3. resolved May 15, 2026, 05:21 PM UTC

   This incident has been resolved. A postmortem will be provided shortly.

4. postmortem May 15, 2026, 06:37 PM UTC

   Warm Transfer Service Disruption — May 15, 2026 Resolved | Impact: 06:00–10:17 AM PDT \(~4 hours\) | Severity: Major What happened For approximately four hours on the morning of May 15, our Warm Transfer feature failed to merge calls between carriers and brokers. From our platform's perspective each merge appeared to succeed at normal volume, but the audio bridge between the two parties did not settle, and both legs dropped before they could speak to each other. Affected calls remained in an "in-progress" status until they timed out on the carrier's side. Service was restored at 10:17 AM PDT after rolling back the responsible deploy. No data was lost. Cause A deploy on the previous afternoon bundled two unrelated changes that, in combination, broke the warm-transfer flow. One change altered how requests are routed within our API, with the side effect of silently rejecting the specific request Twilio makes to fetch the merge-greeting audio. The second change in the same deploy adjusted the timing of an internal step on our side. With the greeting audio no longer playing, the conference attempt was racing against the timing change, and the timing change won; both legs dropped before merging. Either change alone would have been harmless. Overnight traffic was too low to surface the issue; customer-visible impact began as daytime traffic ramped up the next morning. What we're doing Rolled back the responsible deploy and opened a permanent fix for the routing regression, with a test that encodes this bug class. Adding warm-transfer scenarios to our end-to-end test suite that runs in CI before every deploy — this would have caught the regression before it reached production. Restructuring our pull-request process so changes to shared live surfaces are split out of feature pull requests and reviewed separately by a small group of senior engineers. Adding a monitor for the specific symptom we missed: warm-transfer calls recorded as merged whose duration ends abnormally short. Making early-rollback a routine first-pass debugging step when a regression begins close in time to a known deploy. ‌ We're sorry for the disruption. If this incident affected your workload and you'd like a more detailed discussion, please reach out to your account contact.