Degraded Warm Transfers Performance

What to do

• Check whether your product depends on Bland AI. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 2h 26m it lasted.

  Anything that failed between 2026-05-15 14:55 UTC and 2026-05-15 17:21 UTC may need a replay.

• Subscribe to Bland AI's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=bland works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Updates from Bland AI 4

1. investigatingMay 15, 2026, 2:55 PM UTC

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

   provider

2. monitoringMay 15, 2026, 4:03 PM UTC

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

   provider

3. resolvedMay 15, 2026, 5:21 PM UTC

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

   provider

4. postmortemMay 15, 2026, 6: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.

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.