Azure Static Web App — one managed Function returns HTTP 500 before code executes, no exception in Application Insights

Question

Summary: On a Standard-plan SWA with a managed Node Functions API, one HTTP function (responses) returns a blank HTTP 500 on every request, including a code path that returns early before any I/O. A sibling function (admin-coverage) in the same API works correctly (returns expected 403). No exceptions appear in the linked Application Insights.

Environment:

• SWA: XXXXXXXX (Standard plan), region [your region]
• Managed Functions API, Node, Functions runtime ~4 (build log shows node 22)
• Auth: custom OpenID Connect provider (Entra External ID), rolesSource function

What works: Login succeeds (/.auth/me returns correct principal). GET /api/admin/coverage returns a correct 403. Build/deploy is green; build log shows the API building and Deployment Complete.

What fails: GET /api/responses (any query, including a diagnostic param that returns before touching storage) returns blank HTTP 500. The handler is wrapped in try/catch that returns JSON on error, yet the response is a generic 500 with no JSON body — indicating failure before/around function invocation. No exception is logged in Application Insights.

Already tried: Verified function.json route/bindings; verified host.json extension bundle; recreated the entire SWA resource from scratch; confirmed no committed node_modules; removed an engines field; confirmed the rolesSource/role assignment and app settings. Issue reproduces identically across two independently created SWAs from the same repo.

Ask: Please inspect the Functions host startup/invocation logs for the responses function to identify why it returns 500 without executing handler code or logging an exception.

Answer 1

The cause of the 500 error for a single managed function cannot be determined from the available context because there is no access to the specific Functions host logs for that Static Web App.

From the provided guidance, the only supported diagnostics paths are:

1. Validate deployment and folder configuration

• Confirm that the api_location in the Static Web Apps workflow matches the root folder of the Functions app (typically api).
• Misconfigured api_location can cause API issues even when the build is green, and errors may not surface clearly in the app:
  • Either no API directory was specified, or the specified directory wasn't found.
• Ensure the workflow’s app_location, output_location, and api_location are all aligned with the repo structure.

2. Inspect build and deployment logs

• In GitHub → Actions → select the Static Web Apps workflow run → open Build and Deploy Job → Build And Deploy.
• Review the Oryx build output for any warnings or errors related to the Functions runtime or the responses function.

3. Use Application Insights for runtime errors

• Ensure Application Insights is enabled for the Static Web App so that server errors are captured.
• In the Azure portal:
  1. Open the resource group for the Static Web App.
  2. Open the associated Application Insights resource.
  3. Under Investigate, select Failures and drill into failed operations.
• Only errors occurring after Application Insights is enabled will appear.

4. Check for runtime/runtime-detection issues in Node Functions

• For Node-based Functions, verify that any applicationinsights dependency (if present) is at a supported version (for example, ^2.7.1 or higher) to avoid runtime detection issues such as:
  • WARNING: Failed to detect the Azure Functions runtime. Switching "@azure/functions" package to test mode - not all features are supported.
• After changing dependencies, run npm install and redeploy.

5. Confirm platform/runtime constraints

• Managed Functions in Static Web Apps must comply with the documented constraints:
  • HTTP-only triggers and bindings.
  • Supported runtimes only (Node.js 12/14/16/18/20 (preview), .NET Core 3.1, .NET 6/7/8, Python 3.8/3.9/3.10).
  • No use of reserved application setting prefixes (for example, FUNCTIONS_, WEBSITE_, AzureWeb, etc.) or reserved tags (AccountId, EnvironmentId, FunctionAppId).
• If the responses function relies on any setting using a reserved prefix, the host may fail that function at startup.

If these checks do not reveal the issue, the next step is to use the documented support channels for Azure Functions/Static Web Apps and provide them with the Functions host logs and the failing function’s configuration.

---

References:

• Troubleshooting deployment and runtime errors
• API support in Azure Static Web Apps with Azure Functions
• Troubleshoot Node.js apps in Azure Functions (nodejs-model-v4)