Daily Outage History

Started Jun 10, 2026, 07:20 PM UTC· resolved Jun 11, 2026, 02:47 AM UTC

1. identified Jun 10, 2026, 07:20 PM UTC

   We're seeing a recurrence of the problems with RegistryDNS.co and AT&T DNS from Monday. Users trying to join calls from affected regions using ISP DNS may get "Unable to join call" errors. We know specifically that AT&T DNS servers 68.94.157.1 and 68.94.156.1 are affected. We've been working hard on solving this problem since the incident on Monday. We're releasing daily-js 0.91.0 shortly to address this.

2. identified Jun 10, 2026, 07:32 PM UTC

   We expect to have daily-js 0.91.0 available within the next 60 to 90 minutes. The update includes automated failover to `dailywebrtc.com` or `dailywebrtc.net` if `daily.co` is unreachable. If you haven't updated daily-js in a while, you can do preliminary testing with 0.90.0 in order to be ready to release an update with 0.91 as soon as it's ready. 0.91 will only contain this feature, as well as a few dependency version updates for security. If you have customers with restrictive networks, they may need to add `*.dailywebrtc.com` and `*.dailywebrtc.net` to their firewall/security allowlists. These domains are relatively new, so they may be flagged by Cisco app firewalls and similar security appliances.

3. monitoring Jun 10, 2026, 10:07 PM UTC

   daily-js 0.91.0 is now available on npm and GitHub. If your app uses call object mode, you can update your dependency to that version and redeploy, and this issue should be resolved for you. We're publishing an update to our networking guide soon, but in the meantime, anything that mentions a `.daily.co` hostname in that doc is also available at `.dailywebrtc.com` and `.dailywebrtc.net`. We'll have updates for embedded Prebuilt and direct link customers soon. We'll leave this incident open while RegistryDNS.co remains offline.

4. resolved Jun 11, 2026, 02:47 AM UTC

   The RegistryDNS.co servers continue to be intermittently unavailable, but AT&T's DNS servers seem to be more responsive. We encourage you to update to daily-js 0.91.0 as soon as possible to avoid future issues for your users.

Read the full incident report →

Started Jun 08, 2026, 02:32 PM UTC· resolved Jun 09, 2026, 02:57 PM UTC

1. identified Jun 08, 2026, 02:32 PM UTC

   We've identified an issue that's preventing some users from being able to join calls, resulting in errors like "Unable to join call" in the browser. This is being caused by failures from the DNS servers that serve the .co TLD itself. Several third-party DNS providers like Google, Cloudflare, and Quad9 are working around this in order to continue to make .co domains available. But users that are using their ISP's DNS service (specifically AT&T users in the southeast US and/or Texas) are experiencing intermittent problems accessing any .co domain, including daily.co. Unfortunately, the only workaround is to encourage your users to use a third-party DNS provider, like Cloudflare or Quad9. We're working on addressing this long-term.

2. identified Jun 08, 2026, 08:12 PM UTC

   We are working on implementing a fallback to a .com domain so that users on ISPs that are not fixing this will not see any issues starting calls.

3. resolved Jun 09, 2026, 02:57 PM UTC

   CentralNIC confirmed that there was indeed an issue with the .co nameservers, and they resolved it at approximately 06:30 UTC today. Our monitoring of both their DNS servers and downstream providers confirmed this. We're continuing to work urgently on updating our infrastructure to make our services available on alternate hostnames. We'll post updates to our Networking Guide when we do: https://docs.daily.co/guides/privacy-and-security/corporate-firewalls-nats-allowed-ip-list We'll also provide a root cause analysis for this incident in the next few days.

Read the full incident report →

Started Apr 23, 2026, 01:45 AM UTC· resolved Apr 23, 2026, 01:45 AM UTC

1. investigating Apr 23, 2026, 01:45 AM UTC

   tester

2. resolved Apr 23, 2026, 01:45 AM UTC

   Resolved by chad

Read the full incident report →

Started Apr 23, 2026, 01:42 AM UTC· resolved Apr 23, 2026, 01:48 AM UTC

1. investigating Apr 23, 2026, 01:42 AM UTC

   test

Read the full incident report →

Started Apr 17, 2026, 01:33 PM UTC· resolved Apr 17, 2026, 11:06 PM UTC

1. investigating Apr 17, 2026, 01:33 PM UTC

   We're receiving reports of some users having problems connecting to Daily calls. It seems to be localized to the Texas area. We're investigating.

2. identified Apr 17, 2026, 01:54 PM UTC

   We've identified an issue that's causing some users to fail to join calls. The daily-js library has to download a bundle of additional JavaScript as part of joining a call. This bundle is downloaded from c.daily.co, which is using Amazon's CloudFront CDN. They aren't reporting issues yet, but we're engaging with their support to figure out why this is happening.

3. identified Apr 17, 2026, 02:06 PM UTC

   We're receiving reports of a few other regions experiencing similar connection issues. If you're monitoring client errors and you see messages that start with "Failed to load call object bundle https://c.daily.co/....", you're being affected by this. We're working with AWS to get to the bottom of this.

4. identified Apr 17, 2026, 02:56 PM UTC

   We've confirmed through several different end users that this is a DNS issue. Affected users from multiple regions have been able to join calls by pointing DNS to Google or CloudFlare, using IPs like 1.1.1.1 or 8.8.8.8 for DNS. Obviously, this solution doesn't scale; we're working with AWS to identify the root cause of the DNS resolution issue for c.daily.co.

5. identified Apr 17, 2026, 03:50 PM UTC

   Cloudflare has posted an incident concerning intermittent DNS failures for .co domains: https://www.cloudflarestatus.com/incidents/z3b5zxjtp6g1 This aligns with the troubleshooting we've done so far. Some internet discussions suggest that it can be somewhat ISP-dependent, but this is unconfirmed. If this is indeed related to the .co domain itself, it would mean that it affects participants' ability to join calls, but it could also affect the ability to make API requests to api.daily.co. Updates to follow.

6. identified Apr 17, 2026, 06:13 PM UTC

   The .co registry appears to be experiencing issues. Cloudflare's recursive DNS is affected (and they've acknowledged it). Many regional ISPs, such as AT&T in the southeast US, rely on Cloudflare's DNS to power their own DNS. Unlike Cloudflare, other DNS providers, like Google and Quad9, are serving .co records from stale cache. If they stop doing this, then anyone using those DNS services will start to experience these same failures. This won't be fully resolved until the .co registry comes back online. In the meantime, different DNS providers may see problems come and go. All of Daily's services remain online and functional, so if your users can resolve .co hostnames, they can use our services without problems.

7. identified Apr 17, 2026, 06:26 PM UTC

   Cloudflare has posted that they've implemented a fix, and they are monitoring the results. We're still not certain that Cloudflare is the actual root cause of 100% of our affected users, but we'll be monitoring error rates.

8. identified Apr 17, 2026, 08:06 PM UTC

   Cloudflare has resolved their status incident, but we're unsure if that means the underlying issue is resolved. We're continuing to monitor our own error rates and health checks.

9. identified Apr 17, 2026, 09:46 PM UTC

   The rate of bundle download failures has decreased, but it's also tracking our overall usage volume through the day. The number of affected users appears to be very small, but we still have tests that can replicate the failure. Unfortunately this is completely out of our control. If you have users that are continuing to be affected, you can suggest that they use Google's or Quad9's DNS servers at 1.1.1.1 or 9.9.9.9.

10. identified Apr 17, 2026, 11:04 PM UTC

    Our tests just confirmed that DNS resolution is no longer returning errors for .co domains in our tests. This issue has been resolved!

11. resolved Apr 20, 2026, 03:35 PM UTC

    This incident has been resolved.

Read the full incident report →

Started Apr 10, 2026, 03:36 PM UTC· resolved Apr 10, 2026, 04:30 PM UTC

1. investigating Apr 10, 2026, 03:36 PM UTC

   We're seeing an elevated rate of errors for API requests and room joins. We're addressing it right now.

2. monitoring Apr 10, 2026, 03:45 PM UTC

   There was a sudden increase in activity across several databases. We've addressed the cause of the issue, and platform metrics are returning to normal. We're continuing to monitor for any further issues.

3. resolved Apr 10, 2026, 04:30 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 23, 2026, 08:18 PM UTC· resolved Mar 23, 2026, 09:16 PM UTC

1. investigating Mar 23, 2026, 08:18 PM UTC

   We're investigating elevated error rates for incoming PSTN/SIP calls.

2. investigating Mar 23, 2026, 08:29 PM UTC

   SignalWire has identified an issue causing problems with incoming and outgoing PSTN/SIP calls for Daily customers. If you're making dialout calls, you may see an error that says "DialOut stopped: Remote busy or Remote did not answer or Remote ended the call". If you're using dialin, you may hear a message that says "the number you have dialed is not configured correctly and cannot receive calls" or something similar.

3. monitoring Mar 23, 2026, 08:31 PM UTC

   It seems that SignalWire has resolved their issue. We're monitoring for any other problems.

4. resolved Mar 23, 2026, 09:16 PM UTC

   This incident has been resolved. We're still collecting more information on the root cause here; we'll update this status post when we have more info.

Read the full incident report →

Started Mar 16, 2026, 05:12 PM UTC· resolved Mar 16, 2026, 09:57 PM UTC

1. investigating Mar 16, 2026, 05:12 PM UTC

   We're investigating an issue that may be causing delayed delivery for some webhooks.

2. monitoring Mar 16, 2026, 06:31 PM UTC

   We've identified an issue with the webhook system that was causing brief delays when finding meeting start and end events for webhooks. We've addressed that issue. Webhook delivery time was only minimally impacted during the event, and it has returned to normal as of about 15 minutes ago.

3. resolved Mar 16, 2026, 09:57 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 18, 2026, 11:31 AM UTC· resolved Feb 18, 2026, 03:55 PM UTC

1. investigating Feb 18, 2026, 11:31 AM UTC

   We are currently investigating an issue affecting SIP / PSTN inbound calls. Customers may encounter 480 “Temporarily Unavailable” errors when attempting to receive calls. Our engineering team is actively working to identify the root cause and restore service.

2. identified Feb 18, 2026, 02:18 PM UTC

   Our upstream carrier partner has identified the root cause of the issue impacting SIP/PSTN dial-in (inbound) calling and has implemented a fix. Service is beginning to recover, though some degradation may still be present while the fix fully propagates. We are actively monitoring and working to confirm full restoration of inbound calling. Outbound (dial-out) calling remains unaffected.

3. monitoring Feb 18, 2026, 02:19 PM UTC

   The fix from our upstream carrier partner has been applied, and service has been restored for SIP/PSTN dial-in (inbound) calling. We are seeing successful inbound call connections again, and our internal testing confirms recovery. We are continuing to monitor closely to ensure stability and full recovery.

4. resolved Feb 18, 2026, 03:55 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 04, 2026, 11:59 PM UTC· resolved Feb 05, 2026, 08:15 AM UTC

1. identified Feb 04, 2026, 11:59 PM UTC

   We've seen an increase in "Failed to load call object bundle" errors within the past hour. This happens when the browser is unable to download our JavaScript bundle from the CDN. If this happens to you or your users, you should be able to refresh the page and join your call successfully. We're working with our CDN provider to identify the issue.

2. monitoring Feb 05, 2026, 01:44 AM UTC

   The initial increase in error rates has subsided. Based on reports from a few customers, it seems like the impact was primarily in the Texas area. We're continuing to work with AWS to determine the root cause.

3. resolved Feb 05, 2026, 09:49 AM UTC

   The issue has been resolved. We’ve seen the number of “Failed to load call object bundle” errors return to normal levels, and call joins are operating as expected.

Read the full incident report →

Started Feb 02, 2026, 03:45 PM UTC· resolved Feb 02, 2026, 10:37 PM UTC

1. identified Feb 02, 2026, 03:45 PM UTC

   We're tracking a Deepgram incident that is causing problems with transcription events, as well as captions in Daily Prebuilt: https://status.deepgram.com/incidents/rp0jzltym9kw

2. identified Feb 02, 2026, 04:56 PM UTC

   We're continuing to see very brief occurrences of slow or missing transcription data from the Deepgram streaming endpoint. We're talking to Deepgram engineers and continuing to monitor the situation.

3. monitoring Feb 02, 2026, 06:34 PM UTC

   We're seeing extremely low error rates, but Deepgram hasn't resolved their incident yet, so we'll keep monitoring.

4. resolved Feb 02, 2026, 10:37 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jan 26, 2026, 04:47 PM UTC· resolved Jan 26, 2026, 09:24 PM UTC

1. investigating Jan 26, 2026, 04:47 PM UTC

   We are currently experiencing an abnormally large queue of webhooks awaiting delivery. Our team is investigating and working to restore normal processing.

2. identified Jan 26, 2026, 06:03 PM UTC

   We’ve identified the cause of the issue. While a backlog of webhooks remains, we’re actively working to reduce it. Webhook deliveries will continue to be delayed for some time, but no data is being lost.

3. identified Jan 26, 2026, 07:45 PM UTC

   We're continuing to work through a backlog of webhook events, and the delay is starting to decrease. It will still take some time to get fully caught up.

4. monitoring Jan 26, 2026, 08:53 PM UTC

   We've worked through the webhook backlog, and delivery times should be normal. We'll be monitoring for any further issues.

5. resolved Jan 26, 2026, 09:24 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jan 15, 2026, 09:32 PM UTC· resolved Jan 15, 2026, 10:11 PM UTC

1. identified Jan 15, 2026, 09:32 PM UTC

   We're seeing an increased rate of errors when dialing out SIP/PSTN calls.

2. identified Jan 15, 2026, 09:35 PM UTC

   We've rolled back the release that was in process when we started seeing the errors, which seems to have resolved the issue. We'll be monitoring for any regressions.

3. resolved Jan 15, 2026, 10:11 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jan 12, 2026, 09:51 AM UTC· resolved Jan 12, 2026, 11:27 AM UTC

1. resolved Jan 13, 2026, 12:16 AM UTC

   SignalWire experienced an outage earlier this morning. Their status site post is here: https://status.signalwire.com/incidents/MJVYwKKYYwbG Our first customer report of problems was at 1:51 AM PST (09:51 UTC). During the incident, many SignalWire SIP calls were returning 603 Declined. As we were investigating, SignalWire opened an incident on their status site at 2:26 AM PST (10:26 UTC). Their incident post didn't provide enough information for us to determine the overall impact to our customers. As we continued investigating our own logs and pressing SignalWire for more information, our affected customers started reporting that the issue was resolved around 2:35 AM PST. SignalWire ultimately resolved their incident at 03:27 PST.

Read the full incident report →

Started Oct 20, 2025, 12:57 PM UTC· resolved Oct 21, 2025, 03:22 PM UTC

1. identified Oct 20, 2025, 12:57 PM UTC

   AWS is addressing an issue with DynamoDB that is causing problems with many of their services in us-east-1. We have seen issues loading the dashboard and docs sites, and for a few hours we've been unable to log in to Statuspage to update this site. We're sorry about that delay. Up until a few minutes ago, our metrics suggested that core call functionality wasn't being impacted. We just saw a small number of call failures in us-east-1, though. We're continuing to monitor the situation and do what we can to minimize this outage's impact on you and your customers. We'll post more information here as we have it.

2. identified Oct 20, 2025, 03:10 PM UTC

   AWS is continuing to address issues in us-east-1. We're still seeing normal activity levels across our APIs and call servers for this time of day, so we have no reason to believe that any your customers' calls are actually being affected. Part of AWS's mitigation efforts involve limiting the rate at which we can start new call servers. Out of an abundance of caution, we're temporarily removing us-east-1 from our list of available regions for new call sessions. This means your users will likely connect to a call through us-west-2 instead. This failover happens automatically and transparently, and you don't need to do anything. We've already scaled up call servers in us-west-2 to handle the increase in sessions. We'll keep you posted as we continue to monitor the situation.

3. monitoring Oct 21, 2025, 12:50 AM UTC

   AWS has resolved their incident. We're continuing to run the same call servers in us-east-1 as we were before the incident started, but we're still routing the majority of US traffic through us-west-2. We plan to return things to normal tomorrow.

4. resolved Oct 21, 2025, 03:22 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 24, 2025, 06:17 PM UTC· resolved Sep 25, 2025, 09:22 PM UTC

1. investigating Sep 24, 2025, 06:17 PM UTC

   We've temporarily disabled displaying the API and webhook log views on the Dashboard Developer page. The Daily API is still fully operational, and these logs are still being collected. We expect to re-enable these log views in the next few hours. If you have an urgent need for this data, please contact [email protected].

2. resolved Sep 25, 2025, 09:22 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 04, 2025, 02:48 PM UTC· resolved Sep 04, 2025, 04:45 PM UTC

1. investigating Sep 04, 2025, 02:48 PM UTC

   We're experiencing delays in making log data available via the /logs REST API endpoint. We're not losing any log data, but the process that ingests logs for the REST API is bottlenecked. This means that the most recent data available from the /logs endpoint is about 6 hours old. We'll update this incident once the situation has been resolved.

2. resolved Sep 04, 2025, 04:45 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 17, 2025, 08:52 PM UTC· resolved Jul 17, 2025, 09:40 PM UTC

1. investigating Jul 17, 2025, 08:52 PM UTC

   We're investigating reports of SIP/PSTN dialin and dialout failing, or stopping immediately after starting.

2. identified Jul 17, 2025, 09:01 PM UTC

   We're in the process of rolling back a release to address this issue.

3. monitoring Jul 17, 2025, 09:07 PM UTC

   We've rolled back a server release, and the SIP error messages have stopped. We're monitoring for any further problems.

4. resolved Jul 17, 2025, 09:40 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 12, 2025, 06:39 PM UTC· resolved Jun 12, 2025, 09:47 PM UTC

1. investigating Jun 12, 2025, 06:39 PM UTC

   Daily is being affected by widespread internet outages in authentication services. This is currently affecting our ability to collect or view some call metrics. We'll post more as soon as we have more information.

2. identified Jun 12, 2025, 06:56 PM UTC

   This appears to be related to the Google Cloud outage posted here: https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW We'll post here as we learn more.

3. identified Jun 12, 2025, 08:06 PM UTC

   We're seeing some increases in response time from our internal API endpoint that returns connection information to daily-js. This may be causing "room lookup timed out" errors for users attempting to join calls. We believe this is related to the ongoing GCP incident.

4. identified Jun 12, 2025, 08:49 PM UTC

   We had a brief spike in response time, but platform operations appear normal since approximately 20:05 UTC. We're continuing to monitor for any follow-on effects, and we'll leave this status post open until various upstream providers close their respective status incidents.

5. resolved Jun 12, 2025, 09:47 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Apr 17, 2025, 07:33 PM UTC· resolved Apr 17, 2025, 08:36 PM UTC

1. investigating Apr 17, 2025, 07:33 PM UTC

   We're investigating elevated error rates from SignalWire when provisioning SIP/PSTN resources. If you're creating rooms with dial-in or dial-out enabled and it isn't absolutely necessary, you can remove those params from your room creation request to successfully create rooms.

2. identified Apr 17, 2025, 07:57 PM UTC

   SignalWire has confirmed that they made an unannounced change that's causing the problem, and they're working to revert it. We're also working on a quick production update to work around the issue if they can't revert quickly enough.

3. monitoring Apr 17, 2025, 08:11 PM UTC

   It appears that SignalWire rolled back the change, and the errors have stopped. We are monitoring for any further issues.

4. resolved Apr 17, 2025, 08:36 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Apr 15, 2025, 02:11 PM UTC· resolved Apr 15, 2025, 09:56 PM UTC

1. investigating Apr 15, 2025, 02:11 PM UTC

   We're investigating reports of poor quality audio for SIP/PSTN participants in some calls.

2. identified Apr 15, 2025, 04:06 PM UTC

   We've identified an issue causing degraded ("broken up" or "choppy") audio between some Daily sessions and SignalWire SIP/PSTN endpoints. PSTN dialout and PIN dialin do not seem to be affected. SIP dialout seems to be moderately affected. PIN-less PSTN dialin and SIP dialin seem to be experiencing a much higher proportion of affected calls.

3. identified Apr 15, 2025, 07:38 PM UTC

   We've identified an issue with how Daily and SignalWire are negotiating audio codecs for incoming SIP/PSTN calls. We're working on an update that will change the default audio codec used between Daily and SignalWire to Opus. Once this is deployed, you may still experience audio issues if you've explicitly set your SIP audio codec to PCMU as described here: https://docs.daily.co/guides/products/dial-in-dial-out/sip#sip-dial-in-audio-and-video

4. monitoring Apr 15, 2025, 09:33 PM UTC

   We've deployed an update to production servers to remediate the issue, and we're testing to ensure everything is fixed.

5. resolved Apr 15, 2025, 09:56 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Apr 09, 2025, 12:15 PM UTC· resolved Apr 09, 2025, 09:48 PM UTC

1. investigating Apr 09, 2025, 12:15 PM UTC

   We're seeing elevated error rates from our SIP/PSTN provider. If you're creating rooms with dial-in support and getting errors, you may want to retry creating those rooms without dial-in, and then add dial-in with an update REST request.

2. identified Apr 09, 2025, 12:53 PM UTC

   Our SIP/PSTN provider has identified an issue and they're deploying a fix. In the meantime, you should still be able to create Daily rooms without provisioning SIP/PSTN.

3. identified Apr 09, 2025, 01:50 PM UTC

   We're continuing to monitor an issue from our SIP/PSTN provider. The rest of the Daily platform is unaffected. If you're getting an error when trying to create a room, you can remove the dialout_enabled property from the room creation request and try again.

4. identified Apr 09, 2025, 02:26 PM UTC

   We're still monitoring. In addition to dialout_enabled, you'll need to remove other room properties related to SIP/PSTN, dialin, and/or dialout to create rooms.

5. identified Apr 09, 2025, 05:22 PM UTC

   We're still waiting on Signalwire to restore service.

6. identified Apr 09, 2025, 05:46 PM UTC

   We've been told we should be back online after a hotfix at approximately 18:00 UTC, or 15 minutes from now. We'll post another update as soon as we have more info.

7. monitoring Apr 09, 2025, 06:53 PM UTC

   Signalwire has restored service, but we're still seeing some error responses from their API. We believe the majority of room creation failure issues have been resolved. We'll post here again when we've handled this last issue.

8. monitoring Apr 09, 2025, 08:12 PM UTC

   We're still waiting on some additional fixes from Signalwire. Room creation with dial-in/dial-out is working, but you still may experience problems updating dial-in/dial-out settings for existing rooms. Daily Bots and Pipecat Cloud users should be unaffected.

9. resolved Apr 09, 2025, 09:48 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 12, 2025, 03:19 PM UTC· resolved Mar 12, 2025, 08:46 PM UTC

1. investigating Mar 12, 2025, 03:19 PM UTC

   We're investigating an issue that's causing delays in audio connection for a some SIP/PSTN calls.

2. identified Mar 12, 2025, 03:59 PM UTC

   We're getting reports of delayed audio from some customers using SIP dialin and dialout. When the phone user joins the call, they can talk and others will hear them, but the phone user won't hear any audio from other call participants (bot or human) for the first 20-30 seconds. We're continuing to troubleshoot the issue, and we'll post here as soon as we have more info.

3. identified Mar 12, 2025, 06:45 PM UTC

   We've identified the issue, and we're testing a fix in our staging infrastructure. We'll post another update when we've deployed the fix.

4. monitoring Mar 12, 2025, 08:26 PM UTC

   We've deployed a fix, and we're monitoring for any further issues.

5. resolved Mar 12, 2025, 08:46 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jan 28, 2025, 04:21 PM UTC· resolved Jan 28, 2025, 04:58 PM UTC

1. investigating Jan 28, 2025, 04:21 PM UTC

   We're investigating an issue that may be preventing some users from joining meeting rooms.

2. monitoring Jan 28, 2025, 04:36 PM UTC

   We've resolved the issue and we're monitoring to ensure the platform is operating normally.

3. resolved Jan 28, 2025, 04:58 PM UTC

   This issue has been resolved.

Read the full incident report →

Started Nov 25, 2024, 04:48 PM UTC· resolved Nov 25, 2024, 07:26 PM UTC

1. investigating Nov 25, 2024, 04:48 PM UTC

   We're investigating issues that may be causing problems with network connections between regions.

2. investigating Nov 25, 2024, 05:07 PM UTC

   We're continuing to investigate the source of meeting disruptions. Customers may be experiencing 'meeting moves' where a call session moves from one server to another, causing a 2-3 second disruption to the call. You may also see delays in receiving meeting.started and meeting.ended webhooks.

3. identified Nov 25, 2024, 05:10 PM UTC

   We've temporarily disabled the component that sends webhooks.

4. identified Nov 25, 2024, 05:25 PM UTC

   We're addressing an issue with an internal database that's causing problems with existing meetings, as well as starting new ones. Your users are likely seeing some failures when trying to join meeting sessions, and users in ongoing sessions are seeing occasional meeting moves. We'll post more information as soon as soon as it's available.

5. monitoring Nov 25, 2024, 05:33 PM UTC

   We've made some changes to the affected database, and our metrics and error rates have returned to normal. We've also re-enabled delivery of all webhooks, and we're monitoring for any further issues.

6. monitoring Nov 25, 2024, 06:08 PM UTC

   Our metrics have stayed at normal levels since our remediating actions about 30 minutes ago. We're continuing to monitor the platform while we discuss longer-term solutions to make absolutely sure we've addressed the root cause here.

7. resolved Nov 25, 2024, 07:26 PM UTC

   We've deployed an update that increases the throughput of the database that was the bottleneck in today's incident. We'll have more info about additional remediations and a postmortem for today's incident within the next few days.

Read the full incident report →