ThousandEyes actively monitors the reachability and performance of thousands of services and networks across the global Internet, which we use to analyze outages and other incidents. The following analysis of the Zoom outage on April 16, 2025, is based on our extensive monitoring, as well as ThousandEyes’ global outage detection service, Internet Insights. See how the outage unfolded in this analysis—more updates will be added as we have them.
Outage Analysis
[April 16, 2025, 7:00 PM PT]
On April 16, Zoom experienced an outage that impacted users globally. It was first observed around 18:25 UTC and lasted approximately two hours, with the issue being resolved by 20:12 UTC. However, some ongoing disruptions were observed until 20:30 UTC. Zoom acknowledged that the outage was a result of an issue at the DNS layer, and affected connectivity to the zoom.us domain, resulting in disruptions to all services, including the Zoom status page. You can explore the outage in ThousandEyes with no login required here.
What’s DNS and why is it important?
See the explainer here (page 5), but in short, DNS functions like a phonebook for the Internet, making it easier for users to access services by allowing them to type domain names rather than IP addresses. This situation is comparable to a phone service being temporarily disconnected. While an unlisted number in a phone book can still be reached if you remember the phone number, the same is not always true for services that rely on domain names for routing or security purposes, even if you know the specific IP address related to those services.
So, what happened with Zoom?
ThousandEyes’ HTTP Server tests on zoom.us and its subdomains—including app.zoom.us and api.zoom.us—observed a total drop in server availability (see figure 2). ThousandEyes’ agents around the globe were also unable to resolve zoom.us to an IP address during this time.
ThousandEyes’ further investigation using DNS Trace tests indicates that the outage was likely a result of missing records for zoom.us at Zoom’s TLD nameservers (see figure 3). See here (no login required).
The trace results from each agent indicate that the TLD nameservers did not have the records for zoom.us, responding with a non-existent domain error (NXDOMAIN).
What was the impact?
This issue affected zoom.us and all its subdomains, including Zoom customer’s “vanity” names (for example: “acmeco.zoom.us”) as well as Zoom’s own status page, which is hosted at “status.zoom.us”.
The issue had a cascading effect that impacted Zoom's services, particularly their main webpage, zoom.com. ThousandEyes’ agents encountered HTTP 502 Bad Gateway status code responses while trying to access zoom.com. This indicates that the content delivery network (CDN) serving Zoom was unable to connect to the backend services hosted on zoom.us.
It’s worth noting that the authoritative nameservers for zoom.us, which are hosted by AWS Route53, were reachable, available, and seemingly configured correctly for the duration of the outage, and they returned records for zoom.us if queried directly. However, because of the missing NS records at the TLD level, DNS clients were not pointed to the Route53 authoritative namesevers. This highlights the importance of monitoring not only your own nameservers, but the public DNS infrastructure, as well.
When did the outage end?
Zoom acknowledged that access to the domain zoom.us was blocked due to a restriction implemented by their DNS registrar. When a DNS block is enforced by a registry, it prevents the domain name from resolving to its corresponding IP address, making the domain inaccessible.
Following the removal of the block, the service began to come back online around 20:12 UTC, and by approximately 20:30, the incident had largely concluded, with most users able to access Zoom again. Those still experiencing difficulties were advised to flush their DNS cache and reconnect. About two hours after the outage began, Zoom confirmed that the service had been fully restored.
Lessons Learned
For teams operating within complex, interconnected ecosystems, the demand to provide an optimized, always-on experience has never been greater. It's essential to consistently make the right decisions to maintain seamless operations. Identifying a specific fault domain when a service encounters issues requires visibility into performance across the entire service delivery chain.
Applications are made up of multiple components, and to fully understand the entire service delivery chain, teams need to view signals in context throughout that chain. This holistic view helps prevent misinterpretations in cases where the issue affects both the cause determination and aspects such as the service's status page. This understanding shapes the actions your team takes to ensure the continuity or recovery of the affected service. Potential responses could range from switching to an alternative system, implementing mitigations on your end, or choosing to wait for the issue to resolve itself.
To learn more about DNS and how it works, be sure to check out the Internet Fundamentals: Underlying Network Infrastructures Explained. You can also stay up-to-date on the latest Internet outage intelligence by subscribing to our podcast, The Internet Report.
[April 16, 2025, 3:00 PM PT]
ThousandEyes data indicates that the Zoom outage was related to a DNS issue at the ccTLD level. DNS records for zoom.us were not present in the TLD nameserver responses throughout the incident.
Explore the outage in the ThousandEyes platform (no login required)
[April 16, 2025, 2:00 PM PT]
ThousandEyes data shows Zoom users around the globe were unable to access the service on April 16, 2025, from 18:35-20:35 UTC.
Explore the outage in the ThousandEyes platform (no login required)
