Azure Static Web Apps preview API returns 503; Functions deployment fails after successful Python build

Question

Azure Static Web Apps preview API returns 503; Functions deployment fails after successful Python build

McFreeman Family 0

My Azure Static Web App uses the Free plan with managed Azure Functions, Linux, Python 3.11 and Functions runtime v4.

A pull-request preview initially deployed successfully, and its API worked. After adding backend application settings, the preview API began returning HTTP 503: “The service is unavailable.”

Redeploying the same source revision now produces:

“Deployment Failure Reason: Failed to deploy the Azure Functions.”

The build and upload succeed:

Oryx detects Python 3.11.16.
All dependencies install successfully.
API and frontend artifacts are packaged and uploaded.
Deployment then fails after approximately 31 seconds.

Checks completed:

Disabled the optional integration; 503 persisted.
Removed its two encrypted PEM settings and redeployed; failure persisted.
Production's API responded normally when checked.
Activity Log records successful settings updates, with no failed operations in the export.
Content Deployment diagnostics fails to load for both 6-hour and 24-hour ranges.

The timing suggests an environment/configuration relationship, but the cause is unconfirmed.

How can I obtain the underlying managed Functions provisioning or startup error, and recover the preview without modifying production?

I can provide deployment IDs privately to Microsoft staff if needed.

0 comments

1 answer

Your answer

Answer 1

The underlying managed Functions provisioning error requires Microsoft Support when the deployment log and Static Web Apps diagnostics expose only the generic failure; recover safely by replacing the affected PR preview with a newly created preview environment, without merging or redeploying production.

Recover the preview environment

Preserve the failed run first
- Download the complete GitHub Actions log for Build and Deploy Job → Build And Deploy.
- Record the failed deployment ID, commit SHA, PR number, region, and start/failure timestamps in UTC.
- Keep the lines from Finished Upload. Polling on deployment through the final failure.
Check the Free-plan preview count
- The Free tier allows three pre-production environments in addition to production. Close an expendable preview first if that limit is already reached.^1^
Close the affected PR and create a new PR from a new branch
- Closing the PR deletes its temporary environment.
- Create a new branch at the same known revision and open a new PR against the production branch.
- This provisions a distinct preview environment while leaving production unchanged.^2^

This is a preview-state reset and diagnostic test, not a configuration reset. Static Web Apps application settings are copied to staging and production environments, so the new preview inherits the current shared settings.^3^

If the new preview succeeds, the old preview environment was likely stuck. If it fails at the same post-upload point after approximately 31 seconds, escalate rather than repeatedly rebuilding the same artifact.

Obtain the internal error

Managed Functions are deployed and controlled by Static Web Apps. Their documented runtime logging path is Application Insights; the underlying Function App is not exposed like a bring-your-own Function App.^4^

If Application Insights was already enabled before the failure: open the associated Application Insights resource, then select Investigate → Failures → x Operations and inspect the failed request and stack trace. Only errors generated after Application Insights was enabled are available.^5^
If it is not enabled: do not enable it when strict production isolation is required. Enabling it changes the shared Static Web Apps resource, creates an associated application setting, and can collect production API telemetry.^6^

Because Content Deployment diagnostics also fails to load, open the request from the Static Web App resource under Support + Troubleshooting → Create a support request.^7^

Include:

Static Web App resource ID, subscription, region, and Free SKU
PR/environment number and preview hostname
Commit SHA and deployment IDs
Exact UTC timestamps for several failures
Complete action log
Confirmation that Oryx detected Python 3.11.16, installed dependencies, packaged artifacts, and completed upload
The persistent preview 503 and healthy production API
The failed Content Deployment detector behavior
Browser trace captured while reproducing the diagnostics failure, if practical
Correlation or operation IDs if any appear in the workflow, browser trace, or deployment records

Microsoft recommends supplying browser traces, verbose deployment output, and correlation IDs when provisioning failures need support investigation.^8^

Configuration checks that still discriminate

Python 3.11 on Linux with Functions v4 is supported for managed Static Web Apps APIs. Ensure the deployed staticwebapp.config.json explicitly contains:^9^

{
  "platform": {
    "apiRuntime": "python:3.11"
  }
}

Also verify that the workflow’s api_location points to the Functions application root. An incorrect value can still allow the overall build to succeed.^5^

Check newly added setting names against the reserved managed-Functions prefixes, including FUNCTIONS_, WEBSITE_, SCM_, and AzureWeb*.^4^

An open report describes the same Free-tier, managed-Functions, post-upload failure at approximately 31 seconds.^10^ It is supporting evidence of possible platform behavior, not confirmation of this incident’s cause; Microsoft Support must correlate the deployment IDs with the internal provisioning operation.

References