Getting a 409 Conflict error when attempting to create an App Service Plan

Question

I am attempting to create a function app but getting an error message for the app service plan creation.

I have tried deleting another function app to free up a service instance and redeploying, but no luck.

there is no resource still there for either of these.

% az resource show --resource-group rg-egems-temp-metallic-webhook-dev --resource-type "Microsoft.Web/sites" --name metallic-prod-webhook-connector-serviceplan --query id --output tsv

(ResourceNotFound) The Resource 'Microsoft.Web/sites/metallic-prod-webhook-connector-serviceplan' under resource group 'rg-egems-temp-metallic-webhook-dev' was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix

Code: ResourceNotFound

Message: The Resource 'Microsoft.Web/sites/metallic-prod-webhook-connector-serviceplan' under resource group 'rg-egems-temp-metallic-webhook-dev' was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix

Example:

Detected no available instances to satisfy this request for ServerFarm - metallic-prod-webhook-connector-serviceplan

Description: No available instances to satisfy this request.

Recommended Action: App Service is attempting to increase capacity. Please retry your request later. If urgent, this can be mitigated by deploying to a new resource group

Last Error TimeStamp: 2026-07-27 04:12:46

Last Error CorrelationId: 5fbeb35b-6839-2f1e-5f88-7856c6e22756

Total Number of Occurrences: 11

Error Message: No available instances to satisfy this request. App Service is attempting to increase capacity. Please retry your request later or consider enabling Async Scaling on your app service plan: aka.ms/async-scaling. If urgent, this can be mitigated by deploying this to a new resource group.

Answer 1

Hi @John Line ,

Most ASP-creation 409s trace back to this. A webspace is tied to a unique combination of region + resource group + OS, and all plans created with that same combination land in the same webspace. Critically, the webspace is fixed at creation time moving the plan/app to a different resource group afterwards does NOT change it. That's why Azure's error messages keep telling you to "use a different resource group."

Try below steps:

• Deploy into a brand-new resource group (lands you in a fresh webspace with capacity) the officially suggested mitigation, though it fights naming conventions3.
• Retry later - regional scale-out takes time3.
• Try a different SKU/tier (e.g. B2 or S1) then scale up3.
• Check Subscription → Usage + quotas for region/resource-type limits3.
• Note: deleting and recreating the same-named RG often does not help, and the same deployment can succeed from a different account if you see that, please let us know

"Requested features 'Linux Worker, MV3 Series Worker' not available in resource group… Please try using a different resource group or create a new one." The webspace/DU doesn't support the SKU you asked for older DUs may support PremiumV3 but not the newer Pmv3/MV sizes

Moving the plan to another RG won't fix it. You must create a new plan in a NEW resource group in the same region with the target SKU, then create a new app there and migrate settings/bindings across (note: there's no "Clone App" for Linux)2.

"Zone redundancy is not available for resource group ''… Please deploy app service plan to a new resource group." (ZoneRedundancyNotAllowedInResourceGroup / ValidationForResourceFailed) Same webspace constraint the existing webspace isn't zone-redundancy capable. Reported even in supported regions, and notably hitting Windows plans while Linux succeeds (different OS = different webspace)

Update:

Please retry the operation now and check if its working

Hope this helps!

---

If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.

Answer 2

Hello John Line,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you are getting getting a 409 Conflict error when attempting to create an App Service Plan.

The failure is happening during App Service Plan capacity allocation in the selected region/SKU/OS placement. Since you later confirmed that the Australia East regional quota is exhausted, the first required fix is to increase the affected quota, then retry the deployment. Azure quota increases do not create cost by themselves; cost is based only on actual resource usage. - https://learn.microsoft.com/en-us/azure/quotas/quotas-overview

In addition to others who pointed to App Service capacity/resource-group placement, the missing correction is that your validation command checked Microsoft.Web/sites, which is for the Function App/Web App, not the App Service Plan. You must validate the plan using az appservice plan show, az functionapp plan show, or the Microsoft.Web/serverfarms resource type. Azure CLI provides dedicated commands for managing Function App App Service Plans. - https://learn.microsoft.com/en-us/cli/azure/functionapp/plan?view=azure-cli-latest, https://learn.microsoft.com/en-us/cli/azure/functionapp?view=azure-cli-latest

Try the following for best practice approach:

• Request an increase for the exhausted Australia East quota via your Portal.
• Retry creating the App Service Plan after quota approval.
• If the same 409 continues, create the App Service Plan in a new resource group in the same region, same OS, and required SKU.
• If it still fails, test a different compatible SKU or deploy to another acceptable region.
• Escalate to Microsoft Internal or PCS only if quota is available and clean resource-group/SKU/region placement still fails.

This is because creating a new App Service Plan in an existing resource group can fail due to SKU, region, OS, availability zone, or existing Function/Web App compatibility, and the recommended mitigation is to create the plan in a new resource group. - https://learn.microsoft.com/en-us/azure/app-service/app-service-plan-manage

I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

---

Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.

Answer 3

Thanks for your response @Pravallika KV . I checked the usage and quotas, and I have hit the limit on my Australia east region regional vCPUs, which is likely the cause.

Are you aware of if requesting more quota adds additional charges? Or is it just more availability of resources that are then charged when used, ie when the vcpu is consumed? I did not see anything in the documentation about charges for additional quota but wanted to check.

Answer 4

Hi @John Line

Thank you for reaching out to Microsoft Q&A. I understand you are experiencing a 409 issue with Azure App Service.

Based on the error details you've shared, this is a regional/cluster capacity issue, not a naming conflict or a leftover resource problem. The key line in the error is:

"No available instances to satisfy this request. App Service is attempting to increase capacity."

Azure App Service is organized into scale units (clusters) per region. Your resource group is bound to a specific scale unit, and that unit is currently at capacity. Your az resource show confirming the plan doesn't exist rules out a ghost-resource collision.

Options to resolve this

1. Deploy to a new resource group (fastest workaround)

The error message itself recommends this: "If urgent, this can be mitigated by deploying this to a new resource group." A new resource group may be assigned to a different, less-saturated scale unit in the same region.

az group create --name rg-egems-temp-metallic-webhook-dev-2 --location <your-region>

2. Retry later

The platform is actively working to increase capacity. With 11 occurrences over what appears to be a short window, retrying after an hour or two may succeed without any other change.

3. Enable Async Scaling on your App Service Plan

The error references aka.ms/async-scaling as a mitigation. Async Scaling (Automatic Scaling / elastic scale) lets the platform provision instances asynchronously rather than requiring immediate synchronous capacity, which can side-step transient saturation. This applies if you're on a Premium v2/v3/v4 plan.

az appservice plan update \
  --name <your-plan-name> \
  --resource-group <your-rg> \
  --elastic-scale 

4. Deploy to a different region

If your workload is not region-pinned, deploying to an alternate region (e.g., East US 2 instead of East US) is another reliable workaround for capacity saturation.

5. Open a support ticket if urgent

If none of the above unblocks you and the workload is production-critical, file a support request under Service and subscription limits (quotas) → App Service and reference the Last Error CorrelationId: 5fbeb35b-6839-2f1e-5f88-7856c6e22756 from your error output.

---

Please 'Upvote' (Thumbs-up) and 'Accept' as answer if the response was helpful. This will benefit other community members who face the same issue.

Best regards,

Andrew S Taylor