Kudu/SCM Failure on Azure Functions Flex Consumption - Deployment Blocked (404)

Update [Date - e.g., 2025-04-27]: We have since successfully migrated the application to the Classic Consumption plan, where Kudu/SCM is accessible and deployment works as expected (after resolving separate build/runtime issues detailed elsewhere). However, we remain interested in understanding the cause of the Flex Consumption Kudu instability described above for future reference or if others encounter it.

We are encountering a persistent issue preventing deployment to an Azure Functions app configured with the Flex Consumption plan and running .NET 8 Isolated. Our deployment pipeline via GitHub Actions (Azure/functions-action@v1 using Service Principal auth) is failing, and the underlying Kudu/SCM service appears unresponsive.

Problem Details:

1. Kudu/SCM Unresponsive: Accessing the SCM URL consistently returns only a plain text response: {"message":"Kudu WebAPI."}. The expected Kudu dashboard/UI does not load.
2. Deployment Failure: Our GitHub Actions deployment workflow fails at the Azure/functions-action@v1 step with an HTTP 404 Not Found error when attempting to POST the deployment package to the /api/publish endpoint on the SCM site. (Log snippet showing the 404 can be provided if needed).

Troubleshooting Steps Performed:

• Initial State: We initially had runtime instability (HTTP 503s) on the deployed app in West US 3, though deployment reported success. Kudu was inaccessible then (reported 404 initially).
• Successful Isolation Test: We successfully deployed a minimal .NET 8 Isolated function to the same Function App instance (West US 3). That deployment worked, the function ran (HTTP 200 OK), and Kudu logs showed 202 Accepted for /api/publish at that time. This suggested the platform could work.
• Deployment Failure Resumed: When attempting to deploy the main application again, the 404 error during deployment started, and the Kudu {"message":"Kudu WebAPI."} state was observed.
• Restart: Restarting the Function App had no effect on the Kudu state.
• Re-provisioned in West US 3: We deleted the Function App resource and meticulously recreated it with the same name and configuration (Flex Consumption, .NET 8 Isolated, Linux) in West US 3. All settings were reapplied (Storage link, App Insights link, System MI enabled, Storage Blob Data Contributor role assigned to MI on storage via CLI, App Settings restored, az functionapp deployment config set ... --deployment-storage-auth-type SystemAssignedIdentity executed). Result: Kudu still returned {"message":"Kudu WebAPI."}.
• Re-provisioned in West US 2: We deleted the West US 3 Function App again. We created a new Storage Account in West US 2. We created a new Function App in West US 2, linking the new storage and existing App Insights. All configurations were meticulously reapplied targeting the new resources (MI enabled, role assigned on new storage, settings verified/updated, deployment auth command run). Result: Accessing the Kudu URL for the new West US 2 instance still returns {"message":"Kudu WebAPI."}.

Current Status:

We are completely blocked from deploying our application due to this persistent Kudu/SCM service failure on the Flex Consumption plan, which has occurred across two regions (West US 3 and West US 2) even after full resource recreation and careful configuration. We suspect a platform issue or bug related to Kudu initialization on Flex Consumption.

Request:

Could anyone provide insight into this {"message":"Kudu WebAPI."} state for Flex Consumption Kudu sites? Are there known issues or alternative configurations we might be missing? Are there reliable alternative deployment methods confirmed to bypass Kudu entirely for Flex Consumption that work consistently when Kudu is in this state?

Resource Details:

• Function App Name: devassist-func-jayautomataai
• Subscription ID: 3162baf4-ebe6-4af4-ad88-bfee0760362e
• Regions Tested: West US 3, West US 2
• Plan: Flex Consumption
• Runtime: .NET 8 Isolated (Linux)

Thank you for any assistance.