How do I get exceeds quota fixed when it says i cannot upgrade app services. Front Door standard and F1 Web App.

Hi @Paul Styles ,

Thank you for submitting your question on Microsoft Q&A.

Got it that 403 error is almost definitely happening because the Free (F1) App Service plan has hit its daily quota. The Free and Shared tiers have strict CPU and data limits, so once you go over them, the app starts returning “403 – Quota exceeded.” For a .NET 8 Linux container REST API, F1 works only for very light smoke tests, not for any real dev or UAT traffic. A better approach is to set up your test site in East US 2 on a slightly higher tier so it stays reliable without running up your costs.

Scale your App Service Plan up from F1 to Basic (B1), Basic tier removes the daily quota that causes 403, supports Linux containers, custom domains, TLS, and gives you dedicated compute. To control cost B1 is the lowest dedicated tier; keep 1 instance; disable Always On; no deployment slots (those start at Standard), which saves cost.

Portal steps:

Go to App Service > your web app > Scale up (App Service plan).

Choose Basic > B1 and click Apply.

Stay at 1 instance under Scale out.

Az CLI :

# Update the pricing tier to Basic B1
az appservice plan update \
  --name <your-appserviceplan-name> \
  --resource-group <your-rg> \
  --sku B1 \
  --number-of-workers 1

After scaling to B1, your app should stop returning 403 due to quota exhaustion.

For deployment you can keep using your existing GitHub Actions workflow it’ll continue to work even after you scale up the App Service. Since you’re running a Linux container, just make sure the workflow is still pushing your image to ACR or Docker Hub and that the App Service is pulling the updated image.

In the Azure Portal, check Deployment Center to confirm the connection and that your last deployment ran successfully. Then go to Configuration and verify the container settings like DOCKER_REGISTRY_SERVER_URL and DOCKER_CUSTOM_IMAGE_NAME (for example, myregistry.azurecr.io/myimage:tag), along with any environment variables your API needs.

Minimal App Service settings to avoid surprises

• Always On: Off (saves CPU; fine for test/staging; note first request may be “cold”).
• HTTP/2: On.
• Health checks: If you add one, ensure your endpoint is cheap so it doesn’t create unnecessary load.
• Diagnostic logs: Enable App Service Logs > Container logs to see startup issues.
• Ingress: If you’re using private endpoints or IP restrictions, double-check they’re not causing 403s.

Cost‑conscious alternatives (if you want even leaner)

If the app is truly low traffic until spring:

Azure Container Apps (Consumption)

• Scales to 0 when idle; you only pay for actual vCPU/RAM seconds and requests.
• Good for HTTP APIs and background jobs.
• Still supports GitHub Actions and ACR deploys.

Azure Functions (HTTP trigger)

• If your API is stateless and fits the Functions model, serverless can be cheaper and scales automatically.
• .NET 8 isolated worker is supported.

When to stick to App Service: You need full control over the container (custom base images), predictable instance, or long-running requests/sockets.

Reference:

https://learn.microsoft.com/en-us/azure/app-service/app-service-plan-manage?tabs=asyncscaleout

https://learn.microsoft.com/en-us/azure/app-service/web-sites-monitor

Kindly let us know if the above comment helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well

Hi @RAMAMURTHY MAKARAPU ,

Turns out the 403 was an order of operations with the anti-forgery token check. I did a quota request and the scaling worked. I'll monitor addition costs on B1. Pay per use always worries me, I'll monitor the B1 use and see if the container platform makes more sense after a month.

Can’t scale from F1 to B1 – “Operation cannot be completed without additional quota” in East US 2

Updating App Service Plan

Operation cannot be completed without additional quota. Additional details - 
Location: 
Current Limit (Basic VMs): 0  
Current Usage: 0  
Amount required for this deployment (Basic VMs): 1 (Minimum)  
New Limit that you should request to enable this deployment: 1.  

Note that if you experience multiple scaling operations failing (in addition to this one) 
and need to accommodate the aggregate quota requirements of these operations, you will need 
to request a higher quota limit than the one currently displayed.

Not sure how I hit limits unless the visual is a remaining use. looks like i haven't used any quota.

Hi @Paul Styles ,

Thank for the update and the screenshot shows that your F1 App Service plan isn’t using any CPU or memory, but that isn’t the reason you couldn’t scale up. The error you received is caused by a regional quota limit for the Basic tier in that Azure region. In other words, even though your current plan has available resources, Azure won’t allow the upgrade because the region doesn’t have capacity or you’ve reached your allowed quota for that tier.

Why the “Operation cannot be completed without additional quota” error happens:

Every Azure region has quota limits for each App Service plan tier. Free (F1) and Shared plans don’t use dedicated compute, so they never run into these quota limits.

When you try to upgrade to a Basic (B1) plan, Azure must allocate a dedicated Basic-tier VM in that same region.

In your subscription, the quota for Basic-tier compute in that region is currently 0, so Azure cannot provision the required VM.

As a result, the scale-up operation fails, even though your current plan shows 0 CPU and memory usage.

The quota page you’re looking at only tracks F1 (Free tier) limits such as CPU time and memory usage. However, the error you received is related to a completely different type of quota the regional compute quota for the Basic tier.

So even though the F1 quota page shows 0 usage, that doesn’t affect or reflect the Basic-tier regional VM quota, which is what caused the scale-up failure.
Reference:https://learn.microsoft.com/en-us/troubleshoot/azure/azure-kubernetes/create-upgrade-delete/quota-exceeded-during-creation-upgrade?source=recommendations

Kindly let us know if the above comment helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.