Azure App Service: "Cannot find Subscription with name" when creating Microsoft.Web/serverfarms (Linux)

The subscription-specific Microsoft.Web state cannot be inspected from a public Q&A response; use the Priority Community Support ticket linked to this post so an Azure engineer can collect the identifiers privately and escalate the case for backend investigation.

What to do now

1. Check whether this Q&A post has a linked support ticket.
   When the Azure portal routes an eligible technical request to Priority Community Support (PCS), it first creates a support ticket and then prepares the Q&A post. That ticket remains open and linked to the thread. If deeper investigation is required, an Azure engineer can continue privately through Q&A or the email conversation associated with the ticket. ^1^
2. Reply publicly only with confirmation that the problem persists.
   Do not publish the full subscription ID, tenant ID, or unredacted diagnostic output. Provide those only after a Microsoft engineer initiates a private message or through the email conversation attached to the ticket. PCS specifically supports private follow-up for sensitive information. ^1^
3. Prepare this evidence for the engineer:
   • Full subscription ID and tenant ID
   • UTC timestamp of a recent failed attempt
   • Deployment name and correlation ID
   • Complete inner error from the failed Microsoft.Web/serverfarms operation
   • The exact CLI command and --debug output, with access tokens and other credentials removed
   • Confirmation that the subscription is Enabled
   • Confirmation that Microsoft.Web is Registered
   • Confirmation that Portal and CLI fail identically

A correlation ID allows support to identify related events for the failed deployment. ^2^

Collect the deployment details

In the portal:

1. Open Resource groups → realkevbase-rg.
2. Select Deployments.
3. Open the failed deployment.
4. Record its Correlation ID.
5. Open Operation details and capture the complete error for the failed Microsoft.Web/serverfarms operation.

Alternatively, use Azure CLI:

az deployment group list \
  --resource-group realkevbase-rg \
  --query "[?properties.provisioningState=='Failed'].{name:name,time:properties.timestamp}" \
  -o table

az deployment group show \
  --resource-group realkevbase-rg \
  --name <deployment-name> \
  --query "{correlationId:properties.correlationId,error:properties.error}"

To retrieve the failed operation’s inner error:

az deployment operation group list \
  --resource-group realkevbase-rg \
  --name <deployment-name> \
  --query "[?properties.provisioningState=='Failed'].properties.statusMessage.error"

These are the documented deployment-history and failed-operation queries. ^2^

If the unified wizard did not leave a resource-group deployment record, use realkevbase-rg → Activity log, filter for failed operations around the attempt time, and open the event details. ARM deployment errors are available through either Deployments or Activity log. ^3^

If no support ticket is linked

Open Azure portal → Help + support → Create a support request, select the affected subscription, and classify it as an Azure App Service technical issue involving creation of an App Service plan. Do not classify it as billing or subscription management merely to bypass the support-plan restriction; Azure documents technical support as requiring an eligible support plan. The account also needs Owner, Contributor, Support Request Contributor, or equivalent Microsoft.Support/* permission at subscription scope. ^4^

If the Basic plan redirects the technical request to PCS, complete that workflow and publish the generated Q&A post; the resulting ticket provides the tracking and private escalation channel. ^1^

What the current evidence establishes

The identical Portal and CLI failure, despite an enabled subscription and registered Microsoft.Web provider, warrants Microsoft-side investigation, but it does not by itself prove a backend control-plane defect. That diagnosis requires Microsoft telemetry correlated with the failed request.

The reported error also does not match the documented App Service quota signature, which is SubscriptionIsOverQuotaForSku or an explicit zero-limit message. ^5^ Since changing SKUs already produced the same NotFound result, repeating quota, SKU, or provider-registration checks is not the next useful step.

References

1. Get Azure help through Priority Community Support (PCS)
2. View deployment history with Azure Resource Manager
3. Find error codes
4. Create an Azure support request
5. Troubleshoot non-zone-redundant quota requests for Azure App Service