Flex Consumption: zip deploy returns 502 from scm /api/publish since 5 Nov; same command worked before

A Flex Consumption publish to /api/publish can return 502 when the deployment service cannot complete its handoff to the private deployment-storage container; no public Microsoft notice in the available sources confirms a Sweden Central incident matching this exact symptom and date.

Flex Consumption does not use classic Kudu ZipDeploy. Core Tools sends the package to the SCM host’s /api/publish endpoint, after which the deployment service processes it and stores the ready-to-run package in the configured blob container.^1^ Consequently, a healthy running app and a clean activity log do not prove that this separate deployment path can currently reach private storage.

Identify which network boundary is failing

There are two distinct connections:

1. Publishing client → SCM /api/publish
   • If the function app itself has a private endpoint and public access is disabled, the machine or CI agent running Core Tools must have routing and DNS resolution for the app’s private deployment endpoint.
   • Use a connected machine, a self-hosted pipeline agent in the connected network, VPN, ExpressRoute, or a peered VNet with the required routing and DNS.^2^
2. Deployment service → private deployment-storage container
   • Flex Consumption stores code in its configured deployment blob container. Private deployment storage therefore requires the function app’s networking and storage private-endpoint/DNS configuration to permit that access.^3^
   • Verify that the storage account has a blob private endpoint—not only file, table, or queue—and that its private DNS resolves correctly from the VNet used by the function app. Microsoft’s secured-storage guidance specifically requires a blob endpoint and appropriate private DNS configuration.^4^

Because your identical command previously worked and the response arrives in about five seconds, capture a new verbose attempt rather than changing application settings:

func azure functionapp publish <APP_NAME> --verbose

az functionapp deployment source config-zip \
  --resource-group <RESOURCE_GROUP> \
  --name <APP_NAME> \
  --src <PACKAGE_PATH>

The second command uses the supported Flex Consumption package-deployment path and helps determine whether the failure is specific to Core Tools or occurs in the service endpoint itself.^1^ Do not switch to /api/zipdeploy, directly upload the package into the container, or set WEBSITE_RUN_FROM_PACKAGE; those are not the supported Flex Consumption deployment mechanism.

Record for each attempt:

• UTC timestamp
• HTTP status and response body
• SCM request/correlation ID, if returned
• Core Tools and Azure CLI versions
• app name, subscription, region, and deployment-storage account/container
• whether both Core Tools and Azure CLI fail identically

Check whether Sweden Central was affected

The regular resource Activity Log being clean does not exclude a platform incident. In Azure Portal:

1. Open Service Health.
2. Select Health history.
3. Filter by the subscription, Sweden Central, Azure Functions, and the failure period.
4. Open any matching event and inspect its impact and updates.

Service Health is subscription- and region-specific, whereas Azure Status primarily shows broad incidents.^5^ Health History retains inactive events in the portal for up to 90 days; older events can be obtained through the Service Health REST API.^6^

There have been regional Flex Consumption incidents producing HTTP 500-level responses, but the available report concerns West Europe, not Sweden Central, so it cannot establish the cause here.^7^

Escalate if both clients fail

If no Sweden Central event appears and both commands return the same immediate 502, open an Azure support request under Function App → Deployment. Include the UTC attempts, correlation IDs, verbose output, and note that:

• runtime requests remain healthy;
• deployment settings diagnostics are clean;
• storage keys were not rotated;
• deployment storage uses private endpoints with public access disabled;
• the same deployment path worked previously.

Ask support to inspect the regional /api/publish/OneDeploy backend and its connectivity to the configured private deployment container. That backend-side trace is needed to distinguish a regional deployment-service regression from private DNS, routing, or storage authorization failure.

References

1. Package-based deployment for Azure Functions | Microsoft Learn
2. Deployment technologies in Azure Functions (flex-consumption-plan)
3. Azure Functions networking options (flex-consumption-plan)
4. How to use a secured storage account with Azure Functions
5. What is Azure Service Health?
6. Azure Service Health portal
7. Azure Functions App Deployment - Microsoft Q&A