Managed Functions return empty HTTP 500 on every request, across multiple independently-provisioned environments (Standard SKU)

Question

Managed Functions return empty HTTP 500 on every request, across multiple independently-provisioned environments (Standard SKU)

MLU 40

I'm running into a persistent issue where every single request to my Static Web App's managed Functions backend (/api/*) returns an instant HTTP 500 with Content-Length: 0 — no error body at all — regardless of what the function actually does. Static content on the same app serves completely normally.

Environment:

Static Web App, SKU: Standard
Region: Central US
Functions runtime: ~4, Node 22 (confirmed via build logs)
Deployed via GitHub Actions using the standard Azure/static-web-apps-deploy@v1 action

What I've ruled out:

Function code isn't the cause — I deployed a minimal test function with zero dependencies (no require, no external calls, just returns {status:200, body:"pong"}) and it fails identically to my actual functions.
Build/deploy isn't the cause — GitHub Actions logs show a completely clean build: npm install succeeds, Node 22.22.0 is used, Oryx builds and zips the API artifacts without error, and the deploy step reports success.
Not a stuck/corrupted preview slot — I tested this on two completely independent environments: PR #2's managed Function App, and later a brand-new PR (#3) from a different branch, giving a totally separate managed Function App with no shared history. Both environments fail in exactly the same way.
Not a Free-tier limitation — confirmed the app is on the Standard SKU.
Not Authentication — the app's Authentication is set to "Simple" mode; removing unrelated leftover AAD_CLIENT_ID/AAD_CLIENT_SECRET environment variables made no difference.
Not billing — subscription is active and current, no payment issues, amount due is $0.

Additional notes:

Every failed response includes an x-ms-middleware-request-id header, which suggests the failure happens at Azure's platform middleware layer before the function code ever executes.
The portal's own "Diagnose and solve problems" tool errors out with "Sorry, an error occurred" on this resource, for both the "Availability and Performance" and "Configuration and Management" categories — so I haven't been able to get any diagnostics from there either.
Managed Functions under Static Web Apps don't expose a Monitor/Invocations page or accessible Application Insights logs from the portal (Application Insights shows "not applicable" for this resource), so I have no visibility into the actual server-side exception.

Has anyone run into this specific failure mode before, or know of a way to get more diagnostic detail on managed Functions under Static Web Apps? Any pointers on what else might cause a resource-wide (not per-environment) failure like this would be hugely appreciated.I'm running into a persistent issue where every single request to my Static Web App's managed Functions backend (/api/*) returns an instant HTTP 500 with Content-Length: 0 — no error body at all — regardless of what the function actually does. Static content on the same app serves completely normally.

Environment:

Static Web App, SKU: Standard
Region: Central US
Functions runtime: ~4, Node 22 (confirmed via build logs)
Deployed via GitHub Actions using the standard Azure/static-web-apps-deploy@v1 action

What I've ruled out:

Function code isn't the cause — I deployed a minimal test function with zero dependencies (no require, no external calls, just returns {status:200, body:"pong"}) and it fails identically to my actual functions.
Build/deploy isn't the cause — GitHub Actions logs show a completely clean build: npm install succeeds, Node 22.22.0 is used, Oryx builds and zips the API artifacts without error, and the deploy step reports success.
Not a stuck/corrupted preview slot — I tested this on two completely independent environments: PR #2's managed Function App, and later a brand-new PR (#3) from a different branch, giving a totally separate managed Function App with no shared history. Both environments fail in exactly the same way.
Not a Free-tier limitation — confirmed the app is on the Standard SKU.
Not Authentication — the app's Authentication is set to "Simple" mode; removing unrelated leftover AAD_CLIENT_ID/AAD_CLIENT_SECRET environment variables made no difference.
Not billing — subscription is active and current, no payment issues, amount due is $0.

Additional notes:

Every failed response includes an x-ms-middleware-request-id header, which suggests the failure happens at Azure's platform middleware layer before the function code ever executes.
The portal's own "Diagnose and solve problems" tool errors out with "Sorry, an error occurred" on this resource, for both the "Availability and Performance" and "Configuration and Management" categories — so I haven't been able to get any diagnostics from there either.
Managed Functions under Static Web Apps don't expose a Monitor/Invocations page or accessible Application Insights logs from the portal (Application Insights shows "not applicable" for this resource), so I have no visibility into the actual server-side exception.

Has anyone run into this specific failure mode before, or know of a way to get more diagnostic detail on managed Functions under Static Web Apps? Any pointers on what else might cause a resource-wide (not per-environment) failure like this would be hugely appreciated.

0 comments

Answer accepted by question author

Jerald Felix 18,760 Volunteer Moderator

Hi MLU,

The behavior you described does point away from the individual function handler, but I would not treat the x-ms-middleware-request-id header by itself as proof that the failure occurs before Functions invocation.

One useful next diagnostic is to check the Static Web App's FunctionHits and FunctionErrors metrics while reproducing a single failed request. Azure Static Web Apps exposes both metrics specifically for managed APIs. Microsoft documents these under Supported metrics for managed Functions in Azure Static Web Apps.

Open the Static Web App, go to Monitoring > Metrics, select FunctionHits and FunctionErrors, then send one request to a known minimal /api/... endpoint.

If FunctionHits increments, the managed Functions backend is seeing the request. At that point, Microsoft documents Application Insights as the supported mechanism for obtaining request, failure, and trace details for managed Functions.

If FunctionHits does not increment even though /api/* immediately returns the blank 500, or if the Static Web App continues to report Application Insights as "not applicable", that is significant because it suggests the problem is with the managed API integration/provisioning rather than an exception in your JavaScript handler. The managed Function App itself is service-managed, so you do not have the same host-level diagnostic access that you would have with a standalone Function App.

Node.js 22 is currently a supported managed-Functions runtime, so Node 22 alone is not an unsupported configuration. If this answer helps accept it.

MLU 40 Reputation points

2026-09-15T22:28:38.36+00:00

Thanks, that's a great diagnostic — much more precise than what I had. I set up a chart with FunctionHits and FunctionErrors(Sum aggregation) over a 30-minute window, then made a single request to /api/ping (the same zero-dependency test function). Both metrics show -- (no data reported at all) for the entire window, not 0 — so the platform isn't recording any Functions activity for this app whatsoever, even though the request itself returns an immediate blank HTTP 500.

Given your point that this suggests a problem with the managed API integration/provisioning rather than the function code itself, is there anything else on the provisioning side I can check from the portal, or does a resource-wide gap like this (no FunctionHits/FunctionErrors ever recorded, blank 500 on every /api/* call) point to something that really needs a support ticket on Microsoft's end to investigate? Appreciate the help so far.

1 additional answer

Your answer

MLU 40 Reputation points

2026-09-15T22:28:38.36+00:00

Thanks, that's a great diagnostic — much more precise than what I had. I set up a chart with FunctionHits and FunctionErrors(Sum aggregation) over a 30-minute window, then made a single request to /api/ping (the same zero-dependency test function). Both metrics show -- (no data reported at all) for the entire window, not 0 — so the platform isn't recording any Functions activity for this app whatsoever, even though the request itself returns an immediate blank HTTP 500.

Given your point that this suggests a problem with the managed API integration/provisioning rather than the function code itself, is there anything else on the provisioning side I can check from the portal, or does a resource-wide gap like this (no FunctionHits/FunctionErrors ever recorded, blank 500 on every /api/* call) point to something that really needs a support ticket on Microsoft's end to investigate? Appreciate the help so far.

Answer 1

Thanks, that's a great diagnostic — much more precise than what I had. I set up a chart with FunctionHits and FunctionErrors(Sum aggregation) over a 30-minute window, then made a single request to /api/ping (the same zero-dependency test function). Both metrics show -- (no data reported at all) for the entire window, not 0 — so the platform isn't recording any Functions activity for this app whatsoever, even though the request itself returns an immediate blank HTTP 500.

Given your point that this suggests a problem with the managed API integration/provisioning rather than the function code itself, is there anything else on the provisioning side I can check from the portal, or does a resource-wide gap like this (no FunctionHits/FunctionErrors ever recorded, blank 500 on every /api/* call) point to something that really needs a support ticket on Microsoft's end to investigate? Appreciate the help so far.