Increased 503 errors on zoom.us/rec/webhook_download

Description
In the past few days we’ve started seeing an increased rate of 503 error responses when attempting to download cloud recordings via the download url provided in recording.completed (e.g. https://foo.zoom.us/rec/webhook_download/XXX). We can successfully make a follow-up call to the /meetings/{meetingId}/recordings endpoint to get a working url, but these errors have been noisy and increase our processing time.

Error
503 error response from Zoom.

Which App Type (OAuth / Chatbot / JWT / Webhook)?
OAuth

Which Endpoint/s?
rec/webhook_download

Additional context
We started seeing increased 503 errors around 04/27 @ 15:56 UTC and it’s been quite consistent since then.

Hey @ryan,

Thanks for raising this with us.

In order for us to further investigate, can you please share some example recording.completed events and the associated download URLs that threw the 503s? An example or two will be helpful for checking our logs and taking a closer look. You can share this with us at developersupport@zoom.us.

Thanks!
Will

Ok, we’ll spend some time adding some logging so we can provide the payloads. The error rate continues to be very high.

@will.zoom

We’ve also seen this happen for the Panopto App. There has been an uptick in the last hour where 1000’s of the downloads have failed with a 503 response from the server. We did open a ticket about it.

1 Like

Hi @smurray and @ryan,

Thank you for confirming. We are investigating this with priority (ZOOM-269955).

Will

1 Like

Seeing same, but only from some of our servers. Others are connecting with no issues.

We have been using the same reporting.completed trigger to kick off downloads and it worked fine up until a little over a week ago.

On 4/28 we also started seeing a dramatic increase in the number of 503 “service unavailable” errors that have never abated since then. We use the API to download video files for over 400 meetings a day as each one is complete and cannot afford the extra effort it takes to manage exceptions and then go in to pull down missed files. We need this process to work like it did before.

Hey @khronos and @jim.ballowe,

Are you still seeing instances of 503 errors? If so, when was the last instance that you recorded?

Thanks,
Max

We’ve definitely have seen the rate go down today. Our most recent was 05/07 @ ~13:59:58 UTC.

1 Like

Thank you for the report @ryan, I’ll forward that information to our engineering team.

Max

Apologies for the late reply, we don’t have a lot of activity on the weekends. Yesterday (2021-05-11) saw no 503s. :grinning:

Thanks for confirming :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.