App Service Plan Create operation is throttled for subscription

Question

I have been testing around with the Azure App Services and got this error App Service Plan Create operation is throttled for subscription.

As I understand I created too many apps in a short period, how long until I can create a new app again?

Thank you

Answer 1

App Service Plan Create operation is throttled for subscription with 429 status code this error occurs when you have too many deployments/failed deployments of an app service plan within a short period of time. This causes the system to throttle any additional deployments for the next 48 hours. If this occurs, you will need to wait 48 hours to complete a deployment in that region or contact support to see if they will remove the throttle.

This limit is per region, which is why you can able to use other regions.

Quick Solution: use any other region and create a new azure app service it will work fine and resolve your issue.

Answer 2

TL;DR it can take a couple of days for a subscription to settle down regarding quotas [weird but apparently true]

I experienced something similar to @garrison-neely although perhaps even more confusing.

1. Created subscription Friday
2. Saturday/Sunday/Monday created a number of Web Apps for Linux Containers via CI/CD with no problem.
3. Tuesday morning started getting 429 errors (with no Retry-After). We hadn't created hundreds, just 5-6, and not "all at once" but 1 every few hours. Hence, no way we could have got 429 because of "spamming" Azure. So it must have been quota related.
4. Looking at our quota for App Services, it said "0 out of 0", but then when we went to request increase it says "4 out of 0" (because we had indeed created 4 App Service PLANS, but why "out of 0"?!?!)
5. Turned out we couldn't raise a quota request directly via Azure Portal because need to go through our Indirect Partner.
6. After raising quota increase request to partner, 24 hours later got an email from Microsoft (who were looped in by our Indirect Partner) asking us to describe the issue and asking questions all of which had been addressed in our original request to Indirect Partner [classic case of having to reexplain everything after getting passed from support desk to support desk].
7. Now (Wednesday) I went to try it again, and I'm able to create new Web Apps (although quota still says 0 out of 0). Note that I haven't responded to MS support yet, so there is zero chance they've actually done anything.

Anyway, like garrison-neely says it can take a while for new subscription to get fully quota-enabled - what I'm adding is that it can also start off just fine THEN a day or so later get a quota of zero established, THEN a day or so later start working again.

[and note: it's working now, who's to say if it won't stop working tomorrow!]

YMMV but the above was my experience.

Answer 3

I began receiving this error, but without the Retry-After property in the response. After working with Azure support, it turns out newly-created subscriptions take a while to fully allocate in the background. We had to wait 48 hours before the throttling error would go away, and that was what Azure support validated with us.

Once the 48 hours passed (and the new Azure sub was presumably complete in its creation), we no longer received the errors.

Answer 4

As I understand I created too many apps in a short period, how long until I can create a new app again?

We dont have any ideal time that how long until you have to wait to create a new app again.

Throttling happens at two levels. Azure Resource Manager throttles requests for the subscription and tenant.

When you reach the limit, you receive the HTTP status code 429 Too many requests. The response includes a Retry-After value, which specifies the number of seconds your application should wait (or sleep) before sending the next request. If you send a request before the retry value has elapsed, your request isn't processed and a new retry value is returned.

You can determine the number of remaining requests by examining response headers. Read requests return a value in the header for the number of remaining read requests. Write requests include a value for the number of remaining write requests.

You refer this documentation,on how to Retrieving these header values in your code.