Zoom logged two separate service degradations on 24 September, one hitting inbound calls to Zoom Phone and Zoom Contact Center numbers in India, the other knocking out Live Transcription for over six hours. Both faults sat on Zoom's side, not yours.
Started
11:19 UTC
Duration
Lasted 2h 25m
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: Live Transcription, Voice (Inbound/Outbound), Calling (Inbound/Outbound)
What happened?
The first incident started at 11:19 UTC and affected inbound call connectivity to Zoom India phone numbers for Zoom Phone and Zoom Contact Center. Zoom said it was a service degradation tied to a subset of Airtel subscribers, and that outbound calls kept working normally throughout. By 12:07 UTC Zoom had identified the problem as sitting with its underlying carrier, and said it was working with that carrier partner to fix it. The issue was marked resolved at 13:42 UTC, giving a duration of 2h 25m. A second, unrelated incident began at 15:47 UTC, this time affecting Live Transcription services. Zoom's first two updates, at 15:47 and 16:32 UTC, only said it was investigating with no detail on cause. It took until 20:12 UTC, close to four and a half hours later, for Zoom to say the issue had been identified, and monitoring started ten minutes after that. The incident was resolved at 21:57 UTC, a total of 6h 13m. Across both incidents Zoom published nine updates and three components were listed as affected: Voice (Inbound/Outbound), Calling (Inbound/Outbound) and Live Transcription. No user reports were filed in this window. Zoom's status page is the only record here, and at no point does it explain what caused either degradation beyond naming the carrier in the first case.
Learning
Neither of these incidents is the kind your own uptime checks would have caught. A probe that pings Zoom's main service would stay green through an inbound-calling fault scoped to one carrier's subscribers in one country, and through a transcription feature failing while the rest of the call platform works fine. Both readings are correct at the same time: Zoom's core service was up, and a specific feature or route for a specific group of users was broken. That split, where the top-level service is fine but a dependency underneath it fails, is the shape to watch for. Zoom's own history shows 62 incidents in 90 days with a median duration of 49 minutes, so faults like this are routine rather than rare, and most resolve faster than either of today's did. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
