Azure Static Web Apps managed Functions deployment fails after upload on both production deploy and rollback

We are seeing a repeatable Azure-managed Functions deployment failure in an Azure Static Web Apps production/default environment.

Observed behavior

Upload/package phase: SUCCESS Managed Functions provisioning phase: FAILED Elapsed time to failure: ~31 seconds Failure message: Failed to deploy the Azure Functions.

Environment:

• Azure Static Web Apps Free SKU
• Central US
• Linux managed Functions
• Azure Functions v4
• Node.js 22
• Azure Static Web Apps CLI 2.0.7
• Direct, no-build deployment of an already packaged dist/ and api/, including packaged node_modules

Two independent deployments failed in the same phase:

1. The controlled production deployment of a frozen candidate package.
2. The controlled rollback deployment of the same previously working frozen package.

In both attempts, the application and API packages uploaded successfully. The client then polled the deployment twice as InProgress before it became Failed at nearly the same elapsed time:

• First deployment: Failed at approximately 31.21 seconds.
• Rollback deployment: Failed at approximately 31.16 seconds.

Both attempts returned the exact message:

Failed to deploy the Azure Functions.

The following truncated fingerprints matched across both attempts. They are included only to demonstrate payload identity:

• Frozen artifact SHA-256 fingerprint: 5ed77786…7623d
• API content hash fingerprint: f55a01fc…743b

The same frozen package, runtime and no-build deployment method had previously succeeded in an isolated TEST environment, reached Ready, and registered the expected five Functions. This makes an inherent package/runtime incompatibility less likely, although we cannot exclude an Azure backend validation condition without the internal telemetry.

Customer-visible checks completed:

• Node.js 22 with managed Functions v4 is supported for Azure Static Web Apps.
• Documented Free SKU quotas were not exceeded.
• The current production/default build reports Failed.
• Azure Activity Log exposes no corresponding failed ARM operation or inner error.
• The integrated Content Deployment diagnostic exposes no detailed result and currently returns an error.
• Resource Health reports this Static Web App resource type as unsupported.
• No Azure maintenance event was shown for the affected period.
• Five Function names and an HTTP 200 payload are still visible, but they appear to be residual state from an earlier successful deployment and do not validate either failed attempt.

Questions:

1. Is there a customer-visible method to retrieve the managed Functions provisioning correlation ID, inner exception or failing backend substep for this Static Web Apps deployment?
2. If the necessary evidence exists only in Microsoft service-side telemetry, can a Microsoft engineer arrange a private follow-up so we can provide the two deployment IDs, exact UTC timestamps and subscription/resource identifiers without posting them publicly?
3. Is there a known Central US platform, managed Functions provisioning or Free SKU condition that can produce this identical approximately 31-second failure after package upload?

No new deployment attempt has been made. Production DNS, traffic and live data capture remain blocked while this failure is investigated.