Zoom Phone's EU01 cluster had a service degradation affecting inbound and outbound calling for a subset of users. Zoom logged the incident as resolved 17 minutes after it was first posted, though the underlying window ran well before that.
Started
01:07 UTC
Duration
Lasted 17m
Source
IsDown
Next time
Zoom is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Zoom Phone, Calling (Inbound/Outbound)
What happened?
Zoom's status page shows a single incident on 30 September 2026, titled "Service Degradation Affecting Zoom Phone in the EU01 cluster." It touched two components: Zoom Phone and Calling (Inbound/Outbound). The first update, posted at 01:07 UTC and marked "monitoring", is unusual in that it already describes the problem in the past tense. It states that between 21:08 UTC and 00:44 UTC on 09/29 to 09/30, a subset of users may have experienced issues with Zoom Phone in the EU01 cluster, and that the incident had been resolved and services restored. A second update at 01:20 UTC simply confirms the resolution. So the public filing and the actual fault window do not line up cleanly: the posting happened after the fault had already come and gone, and the 17 minute figure on this page covers the time between that first post and the final resolved update, not the full outage itself. Zoom gives no account of what caused the degradation in EU01, and no further detail on which calling functions were affected or how many users saw it. No user reports were filed during this window. Zoom's own history shows 62 incidents in the last 90 days with a median duration of 49 minutes, and 798 incidents all time at a rate of 10.4 per month, so isolated Zoom Phone cluster issues like this are a regular occurrence rather than a one off.
Learning
This incident is a reminder that a status page timestamp is not the same as the fault window. Zoom posted its first update describing an issue that had already run from 21:08 to 00:44 UTC the previous day, and only logged it publicly afterwards, which means anyone relying on Zoom's feed alone would have learned about the problem after it was already over. For a calling feature like Zoom Phone, a cluster level degradation in EU01 can affect call setup or routing without your own application logic ever throwing an error, because your integration only sees Zoom's API responses, not the state of Zoom's internal infrastructure. That is the general shape of this kind of failure: the provider's backend has a localised problem that your own endpoint checks were never positioned to see. UptimeRobot's 30 day data for Zoom shows 28 incidents with a median duration of 31.3 minutes, which is a useful baseline for how often these pass through even when nothing shows up in your own alerts. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
