Is Bland down?

Between 9:45 and 9:53 AM PT (16:45–16:53 UTC), many inbound calls to Bland numbers in the US region failed to connect. Some inbound calls also had slower call setup starting around 9:30 AM PT. The cause was a database slowdown. Inbound calls have connected normally since 9:54 AM PT. We are monitoring while we roll out fixes to prevent this from happening again. Outbound calls were not affected.

This incident has been resolved.

**Summary** On October 19, 2026, from 9:45 to 9:53 AM PT, many inbound calls to Bland phone numbers in our US region failed to connect. From about 9:30 AM PT, inbound calls also took longer than normal to connect. Inbound calls have connected normally since 9:54 AM PT. **What happened** Our primary US database slowed down while it ran required maintenance on several of its largest tables during morning peak traffic. At the same time, long-running queries and a background job tied up database connections. To answer an inbound call, our servers look up the number's configuration in the database. Those lookups took longer than our telephony layer allows, so calls were rejected. Engineers stopped the long-running queries, which freed database capacity, and inbound calls recovered. **Impact** - Inbound calls to US numbers from 9:45 to 9:53 AM PT: many calls failed to connect. - Inbound calls to US numbers from about 9:30 AM PT: calls took longer than normal to connect. - Our other regions, including our FedRAMP environment, were not affected. - We have found no impact on call records or recordings. **What we're doing about it** - We've deployed a time limit on the slow queries involved. The background job no longer holds database connections while it waits. - We're changing how maintenance runs on our largest tables, so it happens in smaller passes and doesn't pile up at peak. - We're limiting how much database capacity a single query can use, and reserving capacity for call setup. - We're adding alerts on inbound call setup time, so we're paged before customers notice. We're sorry for the disruption. If this incident affected your calls, please contact your account team for a closer review.

The issue has been identified and a fix is being implemented.

An upstream outage with our inference infrastructure provider has taken down our primary dialogue LLM cluster, resulting in agent silence. We have blocked further outbound dispatch and are queueing calls. We are moving workloads over to restore functionality.

LLM workload is scaling up in a healthy cluster, expecting 10 minutes until resolution.

Replicas are scaled up in the healthy cluster, monitoring system health and errors now

Replicas are healthy, opening queue back up. Expect a backlog of requests over the next hour

**Summary** On October 14, 2026, from about 3:00 PM to 4:10 PM PT, agents on many calls went silent or took several seconds to respond. Outbound calls requested during the incident were held in a queue and placed late. The queue was fully drained by 4:41 PM PT. **What happened** A data center network outage at our upstream infrastructure provider cut off the cluster that runs the language model our agents use in conversation. The model’s time to first response rose from about 0.3 seconds to more than 7 seconds on average, so agents could not answer callers in time. To keep new outbound calls from connecting into silence, we paused outbound dispatch and queued new requests. The provider moved our model to a healthy cluster, and agents recovered by 4:10 PM PT. We reopened the queue at 4:07 PM PT and released held calls at a controlled rate. **Impact** * Live calls, inbound and outbound, from about 3:00 PM to 4:10 PM PT: agents were silent or slow to respond, and many callers hung up early. * Outbound calls requested during the incident were delayed, typically by 25 to 35 minutes. The backlog cleared by 4:41 PM PT. Calls that were canceled while queued were not placed. * We have found no impact on call records or recordings. **What we’re doing about it** * We’ve deployed a fallback that retries failed conversation requests on a second cloud provider. We’re extending it to switch providers when responses slow down, not only when they fail. * We’re spreading live-call conversation across more than one provider or cluster, so one failure can’t affect every call. * We’re changing agents to recover the turn, for example by asking the caller to repeat, instead of going silent when the model fails. * We’re paging on-call as soon as model response times rise, and slowing outbound dispatch automatically when the model is degraded. We’re sorry for the disruption. If this incident affected your calls, please contact your account team for a closer review.

At 11:15 AM PDT a provider side routing update caused variable extraction requests for fail for some customers. Some post call features were also affected including summary generations and analysis schemas. Fully recovered at 12:11 PM. Timeline: 11:15 AM - Requests begin erroring as the change starts rollout in provider's cluster. 11:20 AM - Rollout completes, error rates for affected models reaches 100%. 11:35 AM - Automated alarms page on call engineering, issue is raised to provider immediately. 11:45 AM - Bland engineering identifies issue as a routing change that expects a new model base URL. 11:50 AM - An override to the new base URL is applied, update begins rolling out to Bland clusters. 12:11 PM - All rollouts completed, error rates return to normal levels.

From about 6:25 AM to 8:35 AM PT, some calls using BTTS V3 voices had delayed or missing agent audio. On affected calls, the agent could go silent for 10 to 30 seconds, and some calls then continued in a fallback voice. Earlier, from about 8:10 PM to 2:00 AM PT, some calls also had intermittent delays before the agent spoke. The cause was a failure in the service that generates BTTS V3 speech. We restarted the service at about 8:20 AM PT, and audio has been normal since about 8:35 AM PT. We’re monitoring while we work on a permanent fix, and we’ll post another update when this is resolved.

This incident has been resolved.

A misconfigured cluster of LLM replicas failed to scale up during our morning burst of traffic, causing high agent response time and possibly complete silence in severe cases between 6:00am and 6:35am PT. After diagnosing the issue we corrected our scale up mechanism to target the correct set of resources, resolving the issue.