LiveKit had 66 outages in the last 2 years totaling 97h 31m of downtime — averaging 2.7 incidents per month.
There were 66 LiveKit outages since July 30, 2025 totaling 97h 31m of downtime. Each is summarised below — incident details, duration, and resolution information.
Between 21:00 and 21:15 UTC, a limited amount of participant subscriptions failed across regions, along with increased subscription latency to subscribers in the Chicago region
Updates to the LiveKit Cloud analytics dashboards are currently delayed due to an issue with our processing pipeline. Ingestion of new data is not affected, and we are in the process of recovering all data. We'll share another update once the restoration is complete and dashboards are updating normally.
Analytics dashboards are updating normally again.
We are currently investigating user reports of SIP invites not getting responses in our Chicago region. We have not yet determined if the issue is due to the users' trunking providers, but we have begun routing traffic away from Chicago to our other US clusters to ensure continued service.
The users who made the original reports are no longer seeing issues. We will continue investigating and post the results of our investigation as soon as they are available, but there are currently no known issues in LiveKit's SIP infrastructure.
We are going to keep traffic routing to our other US clusters, but we will consider this incident closed while we continue to investigate its origin as there is currently no impact to users.
**Root Cause** This issue had the same root cause as the [incident](https://status.livekit.io/incidents/xkcpnmycy5m3) that occurred after it in the US east region. Please view that link for a better understanding of the root cause, technical details, monitoring and mitigations. **Timeline** 2026-02-20 19:00 UTC – Isolated customer reports came in of no sip responses to invites 2026-02-20 20:34 UTC – Looking at various customer examples, we figured out that the common factor in problematic calls was the chicago based SIP loadbalancer. 2026-02-20 21:26 UTC – SIP in Chicago was drained after ensuring it there was enough capacity in other regions.
We are currently investigating reports of elevated API latency in the UK region.
We are routing traffic away from the London cluster to mitigate impact.
We are continuing to investigate the root cause of the performance degradation of the London cluster. We will continue to share updates as we learn more.
All non-pinned traffic has been healthy since we began routing traffic through the nearest healthy nodes at 14:50 UTC. Our team is still working to bring the London cluster back to full health.
We brought the London cluster back to full health at 21:40 UTC. This incident is now resolved. We will publish a postmortem outlining the root cause and the steps we will take to ameliorate this issue in the future as soon as possible.
Our cloud provider’s managed Kubernetes control plane experienced an issue that caused connectivity to cluster nodes to be disrupted, dropping some of the workloads in the cluster. Due to a bug in our auto-draining logic, detection of the issue was delayed. We have since fixed the alerting to ensure faster detection and response if a similar situation occur should occur in the future.
We're investigating an issue with a subset of inference calls made to gemini models.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
Between 16:01 UTC and 16:05 UTC, ~9-10% of participants connecting to the US East region experienced disconnection/reconnection to the RTC service. Client SDKs automatically reconnect and the majority of affected users' access was restored by 16:05 UTC. Cause A code change from a new feature was the root cause of the issue. The new feature is behind a flag which is disabled by default. But, changes to code to support the new feature affected an existing path that did not implement the feature flag, and triggered its use by some mobile phone clients. Resolution The deployment that caused the issue was rolled back. The erroneous code path is being fixed and more tests will be added to ensure that it exhibits expected behavior.
we are investigating reports of connection failures originating from the Chicago region.
the error is due to an expired certificate in the US Central cluster, we are routing traffic around the region
we've resolved the root cause of the expiring cert. service has been fully restored. this impacted core connectivity and API in the US Central (Chicago) region, including RTC, SIP, Phone numbers, Egress, and Ingress post mortem will follow shortly.
The service we use to auto-renew certificates throttles aggressively. When a request to renew a cert is throttled or failed, we automatically retry to renew the certificate. This process usually resolves and the cert is renewed. However, in some cases the renewal process can get stuck; we have alerting set up to catch these instances. Unfortunately a logic error was introduced into this alert and in this case a stuck renewal process did not alert and the certificate eventually expired. We have validated that no other certs are currently in this state. We have also resolved the issue with the alerting. In the future, we'll ensure to monitor changes made to this alerting process to ensure this does not happen again.
We are currently investigating reports of increased API response times for Egress and SIP in our Frankfurt region.
This incident has been resolved. p99 latency between services in the cluster and the DB instance in the eu-central region was elevated from a single cluster. Traffic has been routed around the cluster.
we are observing delays in the analytics data that's visible from the dashboard. we are working on processing the backlog of data. this impacts Session detail page, Egresses, Ingresses, and SIP dashboards. Sessions listing and Agent insights are not affected.
we've implemented fixes to help the data processor to catch up. live processing will be enabled soon.
A fix has been implemented. The processing is back online, and will catch up to real time We will backfill the data for the affected duration next
User traffic was not impacted, but our customer dashboard was not operational because of a major Cloudflare outage. It lasted roughly from 08:45 - 09:15 UTC. https://www.cloudflarestatus.com/incidents/k9ppxftx8bs5 has some details, though it appears the issue may have impacted Cloudflare caching as well. It appears Docker hub may have been impacted at the same time https://www.dockerstatus.com/pages/incident/533c6539221ae15e3f000031/6932a03b2276fb05ff7ee506 but at this point we see no production impact of this on Livekit.
On 2025-12-03 from 15:06 to 15:26 UTC, network connectivity was flapping in our India, Israel, Saudi Arabia and UAE regions. During that period, attempts to initiate RTC connections or API requests to those regions would have failed intermittently. Clients failing to connect would have been routed to a nearby available region on a subsequent attempt. Clients would have experienced a slightly higher join time because of that.
At 11:48 UTC a Cloudflare outage affected the ability to access LiveKit web pages, including www.livekit.io and our Cloud Dashboard (cloud.livekit.io). All other systems remained functional and were unaffected. End user services, including RTC, Ingress, Egress, Hosted Agents, and Inference Gateway remained functional throughout the outage. The issue was resolved by Cloudflare by 17:44 UTC.
We are investigating intermittent issues with creating new cloud agents in EU Central. Running agents in this region are not affected.
The issue has been identified and a fix is being implemented.
A fix has been implemented and we are monitoring the results.
This incident has been resolved. An upstream service provider was having intermittent timeout issues. We've added retries to this interaction and we have not seen a reoccurrence.
We are currently investigating the issue.
A fix has been implemented and we are monitoring the results.
The Reconciler service experienced an interruption, preventing certain changes (e.g., update-secret, deployments, etc.) from being applied to agents during the incident. Creation of new agents was not affected, and only a subset of existing agents were impacted.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
On 2025-10-31 from 06:42 to 06:55 UTC, we detected a cloud provider outage in Frankfurt. We automatically routed around this. After recovery, we noticed elevated RTT to other European clusters, so as a precaution we kept Frankfurt drained until the network proved stable. It was undrained at 09:08.
Our Cloud Provider in Saudi Arabia went down from 7:30 - 8:20 UTC. We automatically route around these issues for unrestricted traffic, but customers with compliance requirements will have noticed a disruption of service.
We are currently investigating the issue. This affects only the analytics dashboard and api. Real time communications is operational
The issue has been identified. Dashboard is now accessible. We are working on restarting the processing pipeline
We are continuing to work on a fix for this issue.
A fix has been implemented. We are continuing to monitor the situation
This incident has been resolved. We will backfill/restore the data
Issues with updating existing cloud agents. Running agents are still working as expected.
The issue has been identified and a fix is being implemented.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.