An Azure service that provides streamlined full-stack web app development.
For Static Web Apps with managed Functions, the supported way to force new code to run is to ensure that:
- The latest build artifacts are actually being used by the SWA environment.
- The Functions runtime has restarted and loaded the new artifacts.
From the available information, the following mechanisms and checks are supported.
- Confirm the deployment actually produced the expected artifacts
Static Web Apps uses the Oryx build process and then validates the configured folders:
-
app_location– root of the frontend source -
output_location– build output folder underapp_location -
api_location– root of the Azure Functions app for managed functions
If these are misconfigured, SWA can successfully run the workflow while still serving older artifacts.
Actions:
- In the GitHub Actions workflow, verify that
app_location,output_location, andapi_locationmatch the repo layout and that the Functions app is under the configuredapi_location. - Check the workflow logs for any of the folder-configuration errors listed in the troubleshooting article (for example, “App Directory Location: '…' is invalid” or “Either no API directory was specified, or the specified directory wasn't found”).
If api_location is wrong or missing, the build may succeed but the live /api route continues to use the previous managed Functions app.
- Verify that the managed Functions app is the one serving
/api
For SWA managed Functions:
- The
/apiroute is fixed. - The source folder for the managed Functions app is controlled by
api_locationin the workflow.
If api_location is changed or misaligned, SWA can end up with an older managed Functions app still serving /api while new builds are going to a different folder that is not wired to the live route.
Actions:
- Confirm that the
api_locationin the workflow is stable and points to the same folder across all commits. - Ensure there is no second Functions app or alternative API configuration (such as API Management or App Service) mapped to
/apithat might be serving an older backend.
- Use Application Insights to confirm which code path is running
Application Insights is the supported way to see runtime behavior for both Static Web Apps and managed Functions:
- For SWA, enable Application Insights on the static web app.
- Use the Failures and operation details views to inspect the exact timestamps and stack traces for the
/apiendpoint.
Actions:
- In the portal, open the resource group → Application Insights instance for the SWA.
- Under Investigate → Failures, drill into failed or successful operations for the signup endpoint and confirm whether any new log markers appear after the deployment time.
If no new markers appear at all, this reinforces that the live Functions host is still using older artifacts or a different API backend.
- What forces a code refresh for SWA managed Functions
The platform behavior for managed Functions in Static Web Apps is:
- The Functions code is deployed as part of the SWA build and deployment pipeline.
- A successful SWA deployment that includes the
api_locationcontent is expected to update the managed Functions app and cause the Functions host to load the new package.
There is no separate restart/stop/start command for managed Functions; the refresh is tied to the SWA deployment itself. The documented mechanisms to influence runtime behavior are:
- Correcting the workflow configuration so the right folders are built and deployed.
- Redeploying via the SWA workflow so that new artifacts are produced and swapped in.
- Using Application Insights to verify that the new code is executing.
- Recommended end-to-end path for this scenario
Given the symptoms (successful builds, old code executing), the most actionable steps supported by the documentation are:
- In the GitHub Actions workflow YAML:
- Confirm
app_location,output_location, and especiallyapi_locationare correct for the repo. - Ensure
output_locationis actually produced by the build (for example, the folder exists afternpm run build).
- Confirm
- Re-run the SWA workflow after any configuration correction and verify in the logs that:
- Oryx builds the expected commit.
- No folder-configuration errors are reported.
- In Application Insights for the SWA:
- Use Failures and operation details to confirm that requests after the deployment time show the new diagnostic log markers.
If, after confirming folder configuration and redeploying, the Functions host still serves old code, this becomes a platform-side issue that requires Azure support to inspect the SWA’s internal deployment state. The public documentation does not expose an additional CLI/portal “force refresh” operation beyond correcting configuration and redeploying.
There is no documented guidance that scaling between Free and Standard, or detaching/reattaching Functions, is required or supported as a normal mechanism to force managed Functions to pick up new code.
References: