Flex Consumption SCM endpoint stays on HTTP 404 after recreating a Linux Consumption Function App with the same name

Question

Flex Consumption SCM endpoint stays on HTTP 404 after recreating a Linux Consumption Function App with the same name

Juan Bosco Rodríguez Martínez 0

We need to migrate a production Azure Function App from Linux Consumption (Y1) to Flex Consumption while preserving its existing default hostname. The hostname cannot change because it is compiled into software installed at customer sites.

Environment:

Region: South Central US
Source: Linux Consumption Y1, .NET 8 isolated
Target: Flex Consumption FC1, .NET 10 isolated, 2048 MB
Azure CLI: 2.88.0
Public network access enabled
The Azure CLI migration assessment reports the source app as eligible. Its only warning is that deployment slots are not supported in Flex Consumption.

Because the default *.azurewebsites.net hostname must be preserved, we cannot use the normal side-by-side migration with a differently named Function App. We backed up the configuration, deleted the Consumption app, and recreated a Flex app with the same name using this command shape:


az functionapp create --name <same-app-name> --resource-group <production-rg> --storage-account <full-storage-resource-id> --flexconsumption-location southcentralus --runtime dotnet-isolated --runtime-version 10 --instance-memory 2048

The ARM create operation completed successfully and the app reported Running. The SCM hostname was present in enabledHostNames and resolved through DNS, but the deployment endpoint remained unavailable:


https://<same-app-name>.scm.azurewebsites.net/api/publish

HTTP 404

This happened twice. On the first attempt SCM returned 404 for the app's entire lifetime of about 11 minutes. On the second attempt it remained 404 for about 7 minutes. We then restored the production app to Linux Consumption successfully. The application is currently healthy.

Deployment results while the recreated production app was on Flex:

az functionapp deployment source config-zip: SCM HTTP 404
az functionapp deploy --type zip: "This API isn't available in this environment yet!"
Azure Functions Core Tools publish: NullReferenceException

We performed several control experiments:

Recreated our test Function App as Flex using the same subscription, region, storage account, runtime and CLI flags. SCM returned HTTP 200 and config-zip reached POST /api/publish, received HTTP 202, and deployed all five functions successfully.
Changed the test app from Y1 to Flex while reusing its name. SCM briefly returned 404 at t+0 but became HTTP 200 within 10 seconds.
Created a Flex app in a brand-new resource group with a new storage account. SCM was available immediately and deployment succeeded.

The package is not the cause: it has host.json at the ZIP root, targets net10.0, and is the exact package successfully deployed to the test app. The failure occurs before code deployment.

The old production Consumption app was hosted on one App Service stamp, while the successful Flex apps were assigned to other stamps. Our current hypothesis is stale routing or site metadata when the same default hostname is immediately reused across Consumption and Flex webspaces/stamps. The production app also had a deployment slot before deletion, which may be another relevant difference.

Questions:

Is there a known SCM provisioning or hostname-routing issue when deleting a Linux Consumption Function App and immediately recreating it with the same name on Flex Consumption?
Is there a required waiting period or readiness check before recreating the same name?
Is checking /api/publish for a non-404 response the correct way to confirm that the One Deploy plane is ready?
Is there a supported migration procedure that preserves the original *.azurewebsites.net hostname?
Could the previous deployment slot affect cleanup or SCM routing after deletion?

We have the exact UTC timestamps, ARM correlation IDs, Activity Logs and sanitized Azure CLI debug logs available for Microsoft staff, but have intentionally not posted subscription-specific identifiers publicly.

Juan Bosco Rodríguez Martínez 0 Reputation points

2026-07-29T06:25:00.2066667+00:00

Additional finding: az webapp deleted list currently shows four historical deleted-site records for the affected app name: three Production records and one former deployment-slot record. The successful test app also has deleted-site records, so their presence alone does not explain the issue. Could Microsoft verify whether any of the production deleted-site records still retain SCM hostname routing or webspace metadata, and whether a backend cleanup is required?
Gursimran Singh 495 Reputation points Microsoft External Staff Moderator

2026-07-29T15:04:28.13+00:00
Hi @Juan Bosco Rodríguez Martínez ,

Thank you for providing the detailed findings.

Based on the available documentation, there is no published guidance indicating that a prolonged SCM HTTP 404 response after recreating a Linux Consumption Function App as Flex Consumption with the same name is expected behavior. Likewise, there is no documented waiting period required before reusing the same *.azurewebsites.net hostname after deleting a Function App. [Migrate Co...soft Learn | Learn.Microsoft.com], [Azure Func...soft Learn | Learn.Microsoft.com]

The fact that deployment succeeds for newly created Flex Consumption apps and for other app names, while the issue occurs only when reusing the production app name, suggests that the deployment package itself is unlikely to be the cause. Since the failure occurs before code deployment and the SCM /api/publish endpoint remains unavailable, further investigation may be required to determine whether any backend provisioning, hostname mapping, deleted-site records, or site metadata associated with the previous app instance are affecting the newly created Flex Consumption app. [learn.microsoft.com]

While deployment slots are not supported in Flex Consumption, the current documentation does not indicate that previously existing slots should prevent successful recreation of the Function App. [Azure Func...soft Learn | Learn.Microsoft.com]

Given the reproducible behavior and the availability of Activity Logs, correlation IDs, deletion timestamps, and CLI debug logs, we recommend engaging Microsoft Support so the service team can review the backend state of the affected app name and verify whether any cleanup or remediation is required. [learn.microsoft.com]

References

Azure Functions Flex Consumption plan hosting: https://learn.microsoft.com/azure/azure-functions/flex-consumption-plan [Azure Func...soft Learn | Learn.Microsoft.com]

Migrate Consumption plan apps to Flex Consumption: https://learn.microsoft.com/azure/azure-functions/migration/migrate-plan-consumption-to-flex [Migrate Co...soft Learn | Learn.Microsoft.com] Please "upvote" if the information helped you. This will help us and others in the community as well.
Juan Bosco Rodríguez Martínez 0 Reputation points

2026-07-29T17:02:11.9866667+00:00

@Gursimran Singh
Thank you for confirming that this is not expected behavior and may require backend investigation.

Unfortunately, the affected subscription currently has the Basic support plan, and the Azure portal prevents us from creating technical support requests. It only permits billing, subscription management, and quota cases.

Since this appears to be a reproducible platform-side provisioning or hostname-routing issue, could you please escalate this Q&A thread to the Azure Functions service team, facilitate a support request on our behalf, or provide a private channel where we can share the affected app name, deleted-site IDs, UTC timestamps, ARM correlation IDs and sanitized CLI debug logs?

We prefer not to post subscription-specific identifiers publicly. The production application has been rolled back and is currently healthy.

1 answer

Your answer

Juan Bosco Rodríguez Martínez 0 Reputation points

2026-07-29T06:25:00.2066667+00:00

Additional finding: az webapp deleted list currently shows four historical deleted-site records for the affected app name: three Production records and one former deployment-slot record. The successful test app also has deleted-site records, so their presence alone does not explain the issue. Could Microsoft verify whether any of the production deleted-site records still retain SCM hostname routing or webspace metadata, and whether a backend cleanup is required?
Juan Bosco Rodríguez Martínez 0 Reputation points

2026-07-29T17:02:11.9866667+00:00

@Gursimran Singh
Thank you for confirming that this is not expected behavior and may require backend investigation.

Unfortunately, the affected subscription currently has the Basic support plan, and the Azure portal prevents us from creating technical support requests. It only permits billing, subscription management, and quota cases.

Since this appears to be a reproducible platform-side provisioning or hostname-routing issue, could you please escalate this Q&A thread to the Azure Functions service team, facilitate a support request on our behalf, or provide a private channel where we can share the affected app name, deleted-site IDs, UTC timestamps, ARM correlation IDs and sanitized CLI debug logs?

We prefer not to post subscription-specific identifiers publicly. The production application has been rolled back and is currently healthy.

Answer 1

Update: resolved

I was finally able to recreate the production Function App with the same name on Flex Consumption.

In my case, the root cause appears to have been orphaned Function host/function-key secret blobs left in the storage account after deleting the original Linux Consumption app. These blobs were stored under the exact prefix:

azure-webjobs-secrets/<function-app-name>/

Deleting the Function App did not remove those blobs because the storage account remained. When the app was recreated with the same name, the new Flex instance found secrets encrypted by the previous app and could not decrypt them.

The symptoms included:

SCM returning HTTP 404 after recreating the app.
az functionapp keys list returning Bad Request.
The portal showing InternalServerError while loading host keys.
Host and function keys not being restored correctly.

The process that worked was:

Back up the application settings, site configuration, deployment package, host keys and every function-level key.
Enumerate and back up all blobs under the exact azure-webjobs-secrets/<function-app-name>/ prefix.
Delete the original Function App.
Delete only the orphaned blobs belonging to that exact app prefix and verify that none remain. Be careful not to delete prefixes belonging to slots or similarly named apps.
Recreate the Function App on Flex Consumption and wait until its SCM endpoint returns HTTP 200.
Restore only the application settings supported by Flex Consumption; deprecated Consumption settings should not be restored.
Deploy the package and restore the host and function-level keys.
Verify that every expected function is registered and run real requests.

After cleaning the stale secret blobs, SCM became available, all keys could be restored, and the five functions were registered successfully. I tested user validation, invoice stamping and cancellation in production; all returned HTTP 200. Application Insights also showed no exceptions or high-severity traces.

Therefore, if an app is deleted and recreated with the same name but SCM or the Functions key APIs behave unexpectedly, I recommend checking whether stale secrets from the previous app still exist in the storage account.

Thanks for the assistance. The migration is now completed successfully.