Bland Outage History

Started Oct 19, 2026, 04:45 PM UTC· resolved Oct 19, 2026, 04:54 PM UTC

1. monitoring Oct 19, 2026, 05:58 PM UTC

   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.

2. resolved Oct 19, 2026, 06:52 PM UTC

   This incident has been resolved.

3. postmortem Oct 19, 2026, 07:09 PM UTC

   **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.

Read the full incident report →

Started Oct 14, 2026, 10:16 PM UTC· resolved Oct 14, 2026, 11:11 PM UTC

1. identified Oct 14, 2026, 10:16 PM UTC

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

2. identified Oct 14, 2026, 10:24 PM UTC

   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.

3. identified Oct 14, 2026, 10:45 PM UTC

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

4. monitoring Oct 14, 2026, 11:01 PM UTC

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

5. resolved Oct 14, 2026, 11:11 PM UTC

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

6. postmortem Oct 15, 2026, 12:49 AM UTC

   **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.

Read the full incident report →

Started Oct 05, 2026, 06:15 PM UTC· resolved Oct 05, 2026, 07:11 PM UTC

1. resolved Oct 05, 2026, 07:47 PM UTC

   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.

Read the full incident report →

Started Sep 25, 2026, 03:41 PM UTC· resolved Sep 25, 2026, 04:00 PM UTC

1. monitoring Sep 25, 2026, 03:41 PM UTC

   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.

2. resolved Sep 25, 2026, 06:43 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 14, 2026, 01:00 PM UTC· resolved Sep 14, 2026, 01:00 PM UTC

1. resolved Sep 14, 2026, 01:52 PM UTC

   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.

Read the full incident report →

Started Aug 27, 2026, 09:00 PM UTC· resolved Aug 27, 2026, 09:30 PM UTC

1. resolved Aug 27, 2026, 09:31 PM UTC

   From 2:00 PM PDT to 2:30 PM a provider outage caused limited inference capacity. Automated monitoring systems restricted outbound call dispatch during the incident. Outbound calls during this window experienced queue delays and elevated latency when they did dispatch, inbound calls were unaffected by queue delays but also experienced higher latency.

Read the full incident report →

Started Jul 14, 2026, 12:45 PM UTC· resolved Jul 14, 2026, 06:15 PM UTC

1. monitoring Jul 14, 2026, 05:54 PM UTC

   A burst of traffic beginning this morning at 5:45am PT has strained global resources, resulting in high LLM response times. We are currently throttling requests until shared model resources recover. Expect slow agent dialogue and knowledge base query response times. Expecting resolution within the next hour.

2. resolved Jul 14, 2026, 06:28 PM UTC

   LLM response times have recovered. A postmortem will be added within the hour.

Read the full incident report →

Started Jun 05, 2026, 01:13 PM UTC· resolved Jun 05, 2026, 04:18 PM UTC

1. investigating Jun 05, 2026, 01:13 PM UTC

   We are investigating reports of missing transcription results affecting some customer's calls.

2. monitoring Jun 05, 2026, 01:23 PM UTC

   A fix has been rolled out and is being monitored.

3. resolved Jun 05, 2026, 04:18 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 15, 2026, 02:55 PM UTC· resolved May 15, 2026, 05:21 PM UTC

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.

Read the full incident report →

Started Apr 13, 2026, 01:34 PM UTC· resolved Apr 13, 2026, 03:10 PM UTC

1. investigating Apr 13, 2026, 02:14 PM UTC

   We are observing heightened API timeouts, affecting both inbound and outbound calling. We are actively investigating the alarms.

2. monitoring Apr 13, 2026, 02:31 PM UTC

   Error rate has decreased, calls and dashboard access are operational again. Continuing to monitor as we investigate root cause.

3. resolved Apr 13, 2026, 03:10 PM UTC

   API is stable, a root cause at the database level has been identified. Once confirmed, postmortem will be updated with findings.

4. postmortem Apr 13, 2026, 05:38 PM UTC

   # **API Service Disruption — April 13, 2026** **Resolved** | Impact: 06:34–07:22 PDT \(48 minutes\) | Severity: Major ## **What happened** For approximately 48 minutes on the morning of April 13, our API was degraded. Most affected requests timed out on the client side after 60 seconds or returned HTTP 5xx errors; voice-call orchestration, SMS send, and webhook callbacks were the most visibly impacted. The service recovered on its own at 07:22 PDT. No data was lost. ## **Cause** A chronic database condition had been accumulating silently for six days: a background replication process prevented our primary Postgres database from reclaiming space left by updated rows, and our busiest update-heavy table gradually developed significant bloat. On the morning of April 13, the resulting slowdown was enough to saturate our API-side connection pools. API workers blocked waiting for the database, new requests queued behind them and hit the 60-second timeout, and the backlog took 40 minutes to drain. ## **What we're doing** * Cleared the stuck replication state and scheduled database maintenance on the affected tables. * Adding monitoring to catch this chronic condition days in advance. * Adding an API-level circuit breaker so a slow database cannot cascade into a stopped API again. * Rewriting the slow query patterns that reduced our operational headroom. ‌ 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.

Read the full incident report →

Started Mar 25, 2026, 02:02 PM UTC· resolved Mar 25, 2026, 02:40 PM UTC

1. investigating Mar 25, 2026, 02:02 PM UTC

   We are currently investigating the issue. Inbound and outbound calls are affected in the US region.

2. monitoring Mar 25, 2026, 02:26 PM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Mar 25, 2026, 02:40 PM UTC

   This incident has been resolved at 7:23am PST. We will follow up with a post-mortem.

4. postmortem Mar 25, 2026, 02:41 PM UTC

   # **Incident: Service Disruption — March 25, 2026** ## **Summary** On March 25, 2026, Bland experienced a service disruption from approximately 6:47 AM to 7:23 AM PT. During this window, call dispatching, API requests, and dashboard access were impacted. Inflight calls were largely unaffected. Full service was restored by 7:23 AM PT. ## **What happened** A routine database migration was applied during a period of elevated traffic. The migration triggered unexpected lock contention in our database, causing connections to stall. While the migration itself completed within 10 minutes, residual connection issues persisted until our engineering team rolled infrastructure containers to restore full connectivity. ## **Impact** For approximately 25 minutes, inbound calls could not connect and outbound calls could not be dispatched. API requests were failing or timing out, and the dashboard, including call logs, was inaccessible. After partial recovery around 7:13 AM PT, some services operated with degraded performance for an additional 10 minutes until full resolution. ## **What we’re doing about it** We are implementing the following changes to prevent a recurrence: **Migration scheduling:** All database migrations will now be applied exclusively during off-hours maintenance windows, aligned with our existing deployment schedule. **In-app status visibility:** We are adding a status page embed directly into the Bland dashboard so that any future incidents are immediately visible to users without needing to check the status page separately. **Infrastructure safeguards:** We are working with our database infrastructure provider to further understand the lock contention behavior and implement safeguards against it. We sincerely apologize for the disruption and take the reliability of our platform seriously. If you have any questions, please reach out to our support team.

Read the full incident report →

Started Mar 24, 2026, 06:24 PM UTC· resolved Mar 24, 2026, 09:03 PM UTC

1. investigating Mar 24, 2026, 06:24 PM UTC

   BTTS V1 is experiencing elevated error rates. We're currently investigating a fix.

2. monitoring Mar 24, 2026, 08:30 PM UTC

   A fix has been deployed and no errors have been observed since 1:18 PM PDT. The team is still monitoring.

3. resolved Mar 24, 2026, 09:03 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 04, 2026, 04:00 PM UTC· resolved Mar 04, 2026, 05:30 PM UTC

1. resolved Mar 04, 2026, 08:59 PM UTC

   Our BTTS service experienced degraded performance due to a failure in our underlying cloud infrastructure's ability to scale compute capacity to meet demand. This resulted in agents stuttering, failing to vocalize responses, increased latency, or producing incomplete audio output during the affected window, for calls that utilize BTTS v2 voices. The timeline was as follows: 6:00 AM PST: BTTS model began failing to scale due to insufficient compute capacity in its assigned cloud cluster. 6:30 AM PST: An automated alert fired but was misconfigured as non-critical and was not actioned. ~8:00 AM PST: Rising call volume exceeded available capacity, causing noticeable impact to production calls. 9:11 AM PST: We identified degraded performance through internal monitoring and began investigating. 9:32 AM PST: BTTS compute was migrated to a separate cloud cluster with available capacity. Scaling resumed normally and performance returned to baseline.

Read the full incident report →

Started Feb 12, 2026, 09:57 PM UTC· resolved Feb 13, 2026, 01:14 AM UTC

1. identified Feb 12, 2026, 09:57 PM UTC

   At 1:32 PM PST database requests began timing out in the Canada region. This has been identified as a database provider outage. Incident is ongoing

2. monitoring Feb 12, 2026, 11:14 PM UTC

   A fix has been implemented and we are monitoring the results.

3. investigating Feb 13, 2026, 12:31 AM UTC

   The database provider is still investigating the root cause. We will update here as soon as we hear updates from them.

4. resolved Feb 13, 2026, 01:14 AM UTC

   The database provider has identified a potential internal networking configuration that may have caused the incident. Database connections and voice agent calls in Canada should be back to normal now.

Read the full incident report →

Started Feb 09, 2026, 07:24 PM UTC· resolved Feb 09, 2026, 07:45 PM UTC

1. monitoring Feb 09, 2026, 08:06 PM UTC

   From 11:24-11:45 PST some calls experienced a disruption where agent audio was not being played, resulting in silence on the call. This issue is fully resolved but full impact is still being investigated.

2. resolved Feb 09, 2026, 08:06 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 04, 2026, 09:00 PM UTC· resolved Feb 04, 2026, 09:00 PM UTC

1. resolved Feb 05, 2026, 02:19 AM UTC

   An increase in database requests resulted in much higher latency, causing the majority of call requests (inbound and outbound) to fail from 12:56-12:59. In progress calls were unaffected.

Read the full incident report →

Started Feb 04, 2026, 09:52 AM UTC· resolved Feb 04, 2026, 11:18 AM UTC

1. resolved Feb 05, 2026, 02:20 AM UTC

   A change to inbound call initialization caused calls to fallback to a default voice rather than the custom voice they were configured with. This impacted the majority of inbound calls from 1:52-3:18 PST.

Read the full incident report →

Started Dec 20, 2025, 11:09 PM UTC· resolved Dec 20, 2025, 11:49 PM UTC

1. resolved Dec 21, 2025, 12:53 AM UTC

   Dialogue generation and most post call processing had high error rates from 3:09 PM - 3:49 PM PST due to a provider outage. During this period the agent was not responding/very slow to respond for some dialogue turns.

Read the full incident report →

Started Dec 09, 2025, 12:36 AM UTC· resolved Dec 09, 2025, 12:43 AM UTC

1. investigating Dec 09, 2025, 12:36 AM UTC

   We are currently investigating the issue of knowledge base queries failing. Calls will fallback to respond without the knowledge base context.

2. investigating Dec 09, 2025, 12:39 AM UTC

   The issue has been resolved.

3. resolved Dec 09, 2025, 12:43 AM UTC

   This incident has been resolved.

4. postmortem Dec 09, 2025, 12:49 AM UTC

   Our containers did not have enough memory for our knowledge base requirements, which was causing the queries to fail as of 11:30am PST today. More resources have been provisioned to the containers with extra bandwidth to prevent the issue from happening again.

Read the full incident report →

Started Nov 19, 2025, 08:27 AM UTC· resolved Nov 19, 2025, 10:04 AM UTC

1. investigating Nov 19, 2025, 08:27 AM UTC

   We are currently investigating an issue of requests routing to api.bland.ai failing.

2. monitoring Nov 19, 2025, 08:44 AM UTC

   The issue looks to have resolved, we are still identifying the root issue.

3. resolved Nov 19, 2025, 10:04 AM UTC

   We will be updating this with a full resolution tomorrow morning. Currently, it looks to be due to a spike in requested data, affecting our database throughput.

Read the full incident report →

Started Nov 06, 2025, 01:00 PM UTC· resolved Nov 06, 2025, 01:00 PM UTC

1. resolved Nov 06, 2025, 01:55 PM UTC

   An issue with an upstream inference provider caused errors in agent dialogue generation for some customers. Traffic was routed to a backup deployment as of 5:11 and error rates have recovered.

Read the full incident report →

Started Oct 23, 2025, 01:19 AM UTC· resolved Oct 23, 2025, 01:34 AM UTC

1. resolved Oct 23, 2025, 12:39 AM UTC

   An upstream provider outage, that provides dynamic feature flag components - suffered a failure in their network configurations. We are assessing this dependency and will ensure it can no longer be a failure point for the dispatching of calls. For clarity, we attach their message below: --- 10/22/2025 17:19:00 GMT-0700 (Pacific Daylight Time) : A network issue that is impacting sdk serving configs was found. Engineering Oncall teams are currently investigating. [Update]: Incident is resolved at 5:34 PM PST.

Read the full incident report →

Started Oct 20, 2025, 05:58 PM UTC· resolved Oct 20, 2025, 07:00 PM UTC

1. identified Oct 20, 2025, 05:58 PM UTC

   Service disruptions with AWS is affecting our upstream provider, causing intermittent issues with dispatching calls.

2. monitoring Oct 20, 2025, 06:08 PM UTC

   The issue looks to be resolved as of 10:56am PST, and had started at 10:40am PST. We will continue to monitor to confirm.

3. resolved Oct 20, 2025, 07:00 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 09, 2025, 08:26 PM UTC· resolved Sep 09, 2025, 08:27 PM UTC

1. monitoring Sep 09, 2025, 08:26 PM UTC

   We experienced an inbound call routing issue from 12:06pm to 12:20pm that prevented inbound calls from connecting properly. Service has been fully restored.

2. resolved Sep 09, 2025, 08:27 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 25, 2025, 05:30 PM UTC· resolved Jul 25, 2025, 07:30 PM UTC

1. resolved Jul 25, 2025, 06:34 PM UTC

   There was an intermittent transcription issue when using Babel due to scaling with our GPU provider, causing audio to not be picked up from the user, that started at 9:30am PST. This has been fully resolved as of 11:30am PST.

Read the full incident report →