Static Web App BYO backend returns HTML 500 before Function execution (invocations stay 0)

Question

Static Web App BYO backend returns HTML 500 before Function execution (invocations stay 0)

Lionel Lapidos 0

We have a production Azure Static Web App with a linked Azure Function App backend.

Current behavior:

User sign-in works normally.
/.auth/me returns a valid clientPrincipal.
API calls from the Static Web App fail with HTTP 500 and content-type: text/html (not JSON):
- GET /api/v1/charts?limit=1
- GET /api/v1/admin/users
- POST /api/v1/charts
x-correlation-id is null on these responses.
Function App Monitor shows no invocation increase for the corresponding functions (stays at 0).

Expected behavior:

Requests should reach the linked Function App and return JSON (including function-level errors), with invocation

telemetry.

Already tried:

Created a new Static Web App and deployed successfully.
Linked backend to Function App.
Confirmed CI/CD workflow and deployment token for the new SWA.
Confirmed Function App auth integration with Azure Static Web Apps (Linked).
Same issue reproduced across two SWA resources.

Impact:

Editors/admins cannot create charts; production workflow is blocked.
Need guidance to diagnose/repair SWA -> linked backend forwarding path.

Golla Venkata Pavani 5,390 Reputation points Microsoft External Staff Moderator

2026-02-25T00:56:23.2366667+00:00

Hi @Lionel Lapidos ,

I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?
Lionel Lapidos 0 Reputation points

2026-02-25T02:25:44.86+00:00

Hi @Golla Venkata Pavani ,

The issue is still unresolved. I have sent you additional details in the private chat
Lionel Lapidos 0 Reputation points

2026-02-26T05:32:25.64+00:00
hi @Golla Venkata Pavani ,

RESOLVED — Root Cause and Full Fix

After extensive debugging, the issue was caused by three compounding infrastructure misconfigurations, none of which produced clear error messages. Sharing the full chain in case it helps others.

Symptom

SWA BYO backend returning HTML 500 errors on all /api/* calls

Zero function invocations in Function App monitor

No X-Correlation-Id header in responses (confirming requests never reached the Function App)

Authentication (/.auth/me) worked normally

Root Cause 1: NAT Gateway had no Public IP assigned

The Function App had VNet integration enabled for outbound traffic, routing through a NAT gateway.

However, the NAT gateway had zero public IP addresses assigned, meaning the Function App had no outbound internet connectivity.

When the SWA proxy forwarded requests to the Function App, the Function App's Easy Auth (App Service Authentication) needed to make an outbound call to login.microsoftonline.com to validate the SWA-issued token. This call silently failed due to no outbound connectivity, causing Easy Auth to reject every request before the function code ever ran —hence 0 invocations.

Fix: Assigned a new Standard SKU public IP to the NAT gateway. The Function App immediately gained stable outbound connectivity.

Root Cause 2: Database IP not whitelisted

With outbound connectivity restored, function invocations now reached the code but failed with a generic 500.

Application Insights revealed: MongoServerSelectionError: Server selection timed out after 5000 ms

The database (MongoDB Atlas) had an IP Access List that did not include the NAT gateway's newly assigned public IP. Previously, without a stable outbound IP, there was no fixed IP to whitelist.

Fix: Added the NAT gateway's public IP to MongoDB Atlas Network Access → IP Access List.

Key insight: If your Function App uses VNet integration + NAT gateway for outbound traffic, your NAT gateway's public

IP is the single IP you need to whitelist in any external service (databases, APIs, etc.). Without a public IP on the NAT gateway, your Function App has no outbound internet access at all.

Root Cause 3: Backend linked to wrong SWA instance

During the original diagnosis of the 500 errors, a second SWA instance was created for testing. The Function App backend ended up linked to the new/test SWA rather than the original production SWA. Since a Function App can only be linked to one SWA at a time, the production SWA had no backend linked and was returning SWA-level 404s for all API routes (with no X-Correlation-Id in responses).

Fix: Unlinked the Function App from the test SWA, relinked it to the correct production SWA.

Diagnostic Steps That Were Most Useful

Checking Function App monitor for invocation count — 0 invocations with SWA 500 = proxy-level failure, not app code

Checking X-Correlation-Id response header — absent = SWA never reached Function App

Direct Function App URL test — returned 401 (confirming Function App itself was reachable publicly)

Function App > Networking — revealed NAT gateway with no public IP and the warning "Your subnet(s) do not have outbound connectivity"

Application Insights KQL query on exceptions with tostring(customDimensions) — revealed the actual MongoServerSelectionError that the app code was swallowing

Browser DevTools Network tab — Content-Type: text/html on 404 with no X-Correlation-Id confirmed SWA-level block vs Function App-level error
Golla Venkata Pavani 5,390 Reputation points Microsoft External Staff Moderator

2026-02-26T15:30:13.2933333+00:00

Hi @Lionel Lapidos ,

Thank you for reaching us about the experiencing an issue where your Azure Static Web App is returning HTTP 500 errors for API calls to your linked Azure Function App backend, and you're not seeing any function invocations.

Here are some things you can check and try out to diagnose and potentially fix the issue:

Double-Check the Backend Linking and Config

Verify in the Azure Static Web Apps portal under Settings > APIs that your Azure Functions backend is listed as Linked for the Production environment. If not, unlink and relink it by selecting the correct subscription, resource, and production slot. Ensure your Static Web App is on the Standard plan (Free doesn’t support BYO backends), and confirm the Function App hasn’t changed the default /api route prefix in host.json, as that can break routing.

Rule Out Networking Blocks

The Function App needs to be publicly accessible for the proxy to work. Head to Function App > Networking > Access restrictions, and confirm there are no IP rules, private endpoints, or VNet integrations blocking traffic. If you can hit the Function App endpoints directly (e.g., https://<function-app>.azurewebsites.net/api/v1/charts) but not via SWA, that's a clue the proxy is the issue.

Verify Authentication Setup

Azure Static Web Apps automatically forwards authentication context to linked backends. When a Function App is linked, Azure configures the Function App authentication provider as “Azure Static Web Apps (Linked)”, which restricts access to requests coming through the Static Web App.

Additionally, authorization rules defined in staticwebapp.config.json apply to /api/* routes and can block API access if misconfigured.

Review Your CI/CD Workflow

Check your GitHub workflow file (for example, .github/workflows/azure-static-web-apps-<name>.yml) and make sure api_location is set to "" so Azure Static Web Apps uses the linked Azure Functions backend instead of managed functions. If it’s set to "api", it may cause conflicts and block request forwarding. After updating, redeploy and review the logs for any errors.

Dig Into Logs for Clues

Enable Application Insights if it's not already on (SWA Standard plan auto-integrates it). In the portal, check SWA > Monitoring > Failures, or query requests with requests | where success == false to spot proxy errors. Do the same for the Function App's Monitor tab.

Reference:

https://learn.microsoft.com/en-us/azure/static-web-apps/functions-bring-your-own https://learn.microsoft.com/en-us/azure/static-web-apps/troubleshooting https://learn.microsoft.com/en-us/azure/static-web-apps/authentication-authorization https://learn.microsoft.com/en-us/azure/static-web-apps/configuration

Kindly let us know if the above comment helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.

2 answers

Your answer

Golla Venkata Pavani 5,390 Reputation points Microsoft External Staff Moderator

2026-02-25T00:56:23.2366667+00:00

Hi @Lionel Lapidos ,

I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?
Lionel Lapidos 0 Reputation points

2026-02-25T02:25:44.86+00:00

Hi @Golla Venkata Pavani ,

The issue is still unresolved. I have sent you additional details in the private chat

Answer 1

Hi @Lionel Lapidos ,

Thank you for the detailed investigation and for sharing the resolution.

The HTTP 500 errors from the Azure Static Web App (SWA) BYO backend were caused by three combined infrastructure issues:

NAT Gateway had no Public IP

The Function App was using VNet integration with a NAT Gateway, but the NAT Gateway had no Public IP assigned. This blocked all outbound internet traffic, causing Easy Auth token validation to silently fail before the function code executed, resulting in 0 invocations and SWA 500 errors.

Recommendation: Assigned a Standard Public IP to the NAT Gateway to restore outbound connectivity.

Database IP Not Whitelisted

After outbound connectivity was restored, function executions failed due to:

YAML

MongoServerSelectionError:

The NAT Gateway’s Public IP was not added to MongoDB Atlas IP Access List.

Recommendation: Whitelisted the NAT Gateway Public IP in MongoDB Atlas.

Function App Linked to Wrong SWA

The Function App backend was linked to a test SWA instance instead of production. Since a Function App can only be linked to one SWA at a time, the production SWA had no backend and returned SWA-level errors.

Recommendation : Unlinked from test SWA and relinked to the correct production SWA.

Kindly let us know if the above comment helps or you need further assistance on this issue.

Could you Please click "Accept the answer” and Yes, this can be beneficial to other community members.

If you have any other questions, let me know in the "comments" and I would be happy to help you

Answer 2

AI answer

It seems that your Azure Static Web App (SWA) is not properly forwarding requests to the linked Azure Function App, resulting in HTTP 500 errors without any invocation increase. Here are some steps you can take to diagnose and potentially resolve the issue:

Check API Location Configuration: Ensure that the api_location in your SWA configuration is correctly pointing to the root folder of your Azure Functions application, typically named api. If this is misconfigured, the requests may not reach the Function App.
Review Application Insights: If you have Application Insights set up, check for any runtime error messages that may provide more context on the issue. You can find these by navigating to your Application Insights instance in the Azure portal and looking under the Failures section.
Validate Deployment Logs: Review the deployment logs in your GitHub Actions for any errors or warnings that might indicate issues with the build or deployment process. Ensure that the deployment workflow is correctly configured to include the necessary API endpoints.
Function App Authentication: Since you've confirmed that the Function App auth integration is linked, double-check that the authentication settings are correctly configured to allow requests from your SWA. This includes ensuring that the authentication tokens are being passed correctly.
Test Directly Against Function App: As a troubleshooting step, try calling the Function App endpoints directly (bypassing the SWA) to see if they respond correctly. This can help determine if the issue is with the Function App itself or the forwarding from the SWA.
Inspect CORS Settings: Ensure that the CORS settings on the Function App allow requests from your SWA domain, as restrictive CORS settings can lead to failed requests.

If the issue persists after these checks, consider reaching out to Azure support for further assistance, as they can provide more detailed diagnostics specific to your environment.

References:

AI-generated content may be incorrect. Read our transparency notes for more information.

Share via

Static Web App BYO backend returns HTML 500 before Function execution (invocations stay 0)

2 answers

Your answer