App Service B1 creation reports quota 0 while Central US quota views show B1 limit 30 and Total Regional VMs limit 31

There is no documented customer-facing read-only API that resolves a failed App Service request to the precise internal quota counter; the supported read-only evidence is the failed ARM operation in Activity Log, correlated with the App Service quota dimensions of subscription, region, deployment type, and SKU.

Recover the request scope without another deployment

Because the submitted JSON was not retained, inspect the original control-plane event:

1. Open Azure portal → Monitor → Activity log.
2. Select the affected subscription and a time range containing November 7, 2026.
3. Filter:
   • Resource provider: Microsoft.Web
   • Resource type: Microsoft.Web/serverfarms
   • Status: Failed
   • Resource group and caller, if known.
4. Open the failed write operation and inspect JSON and Properties.
5. Preserve:
   • correlationId
   • operation name
   • event timestamp
   • resource ID and region
   • status code/message and any nested response
   • request or property values if present
   • deployment name and operation ID

Activity Log automatically records control-plane operations, including Resource Manager deployment errors, and retains them for 90 days. It can be queried by time, resource provider, resource, or correlation ID.^1^ App Service Activity Log entries can include operation, caller, time, status, and property values.^2^

If this was an ARM/Bicep deployment, also check Resource group → Settings → Deployments → failed deployment → Error details, then inspect its operations. Azure CLI can retrieve retained deployment-operation properties without replaying the deployment:^3^

az deployment operation group list \
  --resource-group "<resource-group>" \
  --name "<deployment-name>" \
  --query "[*].properties"

These records may recover the effective request properties. They are not guaranteed to reveal an internal quota resource identifier or the backend’s counter-selection logic. If neither Activity Log nor deployment operations contains the deployment-type value, the source-derived settings cannot retrospectively prove which counter the failed request selected.

Dimensions that must match

For a standard non-zone-redundant App Service plan, compare all four documented quota dimensions:

• Subscription
• Region: Central US
• Deployment type
• App Service plan SKU: B1

App Service quota is scoped by exactly those dimensions.^4^ Therefore, identical B1, usage, and limit labels do not by themselves prove that the usages response, portal row, and failed request addressed the same deployment-type bucket.

Also distinguish:

• B1 VMs: the individual SKU quota.
• Total Regional VMs: an aggregate across individual App Service SKUs in the region.

A deployment must have room in both counters; the lower available amount governs. Your displayed values—B1 0/30 and regional total 0/31—would permit one instance if they belong to the same deployment scope used by the request. Total Regional VMs is not a replacement for the B1 counter and cannot be adjusted directly.^4^

OS should not be inferred as a separate quota dimension merely because the request was Linux. The published scope names deployment type, not OS, and the supplied documentation does not define how Linux maps to that deployment-type value. That mapping—or evidence that the denial used a stale/different backend record—requires Microsoft-side telemetry if it is absent from the failed operation.

The general Microsoft Quota API does not fill this gap: its documented providers include Compute, HDInsight, Machine Learning, Network, and Purview, but not Microsoft.Web.^5^ The App Service REST surface does expose Get Usages In Location, but the documentation supplied here does not state that it returns the internal counter identifier or all deployment-scope dimensions used during admission.^6^

Escalation under Basic support

Azure provides support for quota adjustments without requiring a technical-support plan, while investigation of a backend discrepancy is technical support and normally requires a qualifying support plan.^7^

The documented no-charge path does not establish a separate “investigation only, no quota change” entitlement under Basic support. The legitimate options are:

1. In the App Service quota experience, use a support-request link only if the experience presents one. Microsoft documents escalation when the automated request cannot be fulfilled, but that workflow is still framed as quota handling.^4^
2. Open Help + support → Create a support request → Service and subscription limits (quotas) and describe it explicitly as an existing-quota consistency investigation, including:
   • private subscription ID
   • Central US
   • B1
   • intended deployment type
   • exact timestamp and correlation/request IDs
   • complete 401 response
   • Activity Log/deployment-operation JSON
   • screenshots or exports showing B1 0/30 and Total Regional VMs 0/31
   • statement that no increase or reprovisioning is requested

If that route requires a higher numeric limit and provides no escalation link, the published support boundary does not provide another no-charge investigation-only channel. Resolving the internal counter selection would then require a technical-support entitlement; the public Azure Support REST API likewise requires Professional Direct, Premier, or Unified support to create technical tickets.^8^

References

1. Activity log in Azure Monitor
2. Monitor Azure App Service
3. Find error codes
4. Troubleshoot non-zone-redundant quota requests for Azure App Service
5. Azure Quota Service API
6. Resource Manager
7. Create an Azure support request
8. Azure Support REST API Reference