Static Web App: API routes return 500 error without invoking functions

Thanks both — I checked the APIs blade you pointed me to, and it turns out this rules something out rather than confirming it.

Production shows a dash (expected — production still has an old placeholder page deployed with no API at all), but the PR preview environment we've actually been testing against shows Backend Type "Function App" with Backend Resource Name "(managed)". Clicking into it opens a "Backend Details" panel that explicitly lists all three of my functions by name: create-payment-intent, ping, and update-payment-intent. So Azure's control plane did correctly detect and register all three functions — the registration/discovery theory doesn't seem to be what's happening here.

I also went back and checked the FunctionHits metric more carefully. It has no dimension to filter or split by (Add filter is disabled), meaning it's aggregated across the entire resource, all environments included — and it still shows zero hits over the last 24 hours, despite multiple verified /api/ping requests I sent to the PR environment during that exact window (a zero-dependency function that just returns a hardcoded 200).

So to summarize where this leaves things: the functions are correctly built, deployed, and registered with Azure, but genuinely zero requests have ever reached one, ever — not a scoping artifact, not a missing dimension, just zero. /api/ping still returns an empty HTTP 500 (content-length: 0) on every call. This looks like a runtime/routing failure between the edge and the registered Functions host, downstream of a completely correct deployment. Does this change where you'd look next, or is there a portal/CLI diagnostic that could show what's happening at that specific layer?

Hi @MLU ,

Thanks for checking, that rules out the simplest deployment and discovery failure. The Backend Details panel shows that Static Web Apps recognized a managed backend for the preview environment and knows about all three functions. What it does not establish is that the Functions host serving that environment subsequently completed startup and loaded those modules successfully. A host that fails during startup is consistent with everything you describe: functions listed, FunctionHits at zero, and an empty 500 on every route. The zero FunctionHits value in particular fits requests failing before a normal function invocation is recorded.

The detail that matters here is that ping is not isolated at runtime. Under the v4 model, the files covered by main are the app's registration entry points and are loaded as part of startup. If create-payment-intent.js or update-payment-intent.js throws while it is being evaluated, function registration may not complete, which can make ping unavailable even though ping.js itself has no dependencies. A typical example is a payment SDK client created at the top of the file:

const { app } = require("@azure/functions");
const Stripe = require("stripe");

// runs when the host loads the file, not when a request arrives
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

app.http("create-payment-intent", { ... });

If STRIPE_SECRET_KEY is missing or empty in the preview environment, the constructor throws during module evaluation, before app.http is reached and before any request exists. The same happens with an import of a package that is installed locally but missing from dependencies in api/package.json. In both cases the ping handler is never called, so its content is irrelevant.

Two ways to test this:

1. Push a commit to the PR branch that temporarily removes the two payment functions from main (or deletes their files), so the deployment contains only ping. If /api/ping returns 200 afterwards, you have isolated the failure to one of those two modules or to the configuration and dependencies they require.
2. Check the preview environment's application settings specifically. Settings are copied to staging environments by default, but they can also be set per environment in the Environment variables blade, so a setting that exists for Production is not automatically what the PR environment sees.

For the diagnostic surface you asked about: for managed functions, runtime logs are only available after Application Insights is enabled. Enable it, reproduce the request against the preview URL, and inspect Failures as well as the exceptions, traces and requests tables around that time. If the backend reaches the Functions runtime far enough to emit telemetry, module-loading or startup failures may show up there. If repeated preview requests produce no corresponding telemetry at all, that is useful evidence for the support case that the failure occurs before the instrumented Functions workload handles the request, as @Allan Solomon Mejia suggested.

I would run test 1 before anything else. It costs one commit and separates "one of my files breaks the host" from "the platform is broken" in a way no portal view currently can.

Drafted with help from Claude, disclosed per the Q&A AI usage policy. Documentation claims checked against the Azure Functions Node.js v4 migration guide and the Azure Static Web Apps documentation on application settings and API support. The startup-failure interpretation of the symptoms is my reading, not documented behavior.

Thanks, Fabian — I checked, and this codebase doesn't match that pattern. Both create-payment-intent and update-payment-intentconstruct their Stripe client lazily, inside the request handler (const stripe = Stripe(stripeSecretKey);), only after a guard that checks process.env.STRIPE_SECRET_KEY is present — never at module load time. So a load-time crash in those files isn't possible here.

To test your theory empirically anyway, I removed both payment functions from the deployment entirely (moved them out of /api, redeployed) so that only the zero-dependency ping function remained — no Stripe import, no other functions to interfere. Rebuild and deploy succeeded (confirmed via the Actions log). /api/ping still returned HTTP 500 with content-length: 0, identical to before.

That rules out the payment functions as a cause. At this point the only registered function in the deployment is a hardcoded 200 responder with zero dependencies, and it still 500s with zero bytes of body and zero FunctionHits in Metrics. I think this narrows it down to something in the Functions host/runtime layer itself for this Static Web App resource, rather than anything in the app code.

Hi @MLU ,

Thanks for running both tests; that is a clean result. With a single zero-dependency function still returning an empty 500 on node:20, the function implementation itself is effectively out of the picture. What the ping-only deployment still shares with the failing one is the surrounding app configuration (host.json, api/package.json, staticwebapp.config.json) plus the Static Web App resource and its managed Functions deployment. Those are the remaining variables, and they can be isolated independently.

1. New resource, same branch. Create a second Static Web App in another supported region, such as West Europe or East US 2, and point it at the same repository and branch with the same app_location, api_location, and output_location. Then call /api/ping on the new default hostname. If it returns 200 there, the same repository and deployment layout work on a newly provisioned managed Functions deployment, which strongly isolates the fault to something specific to the original Static Web App resource or its managed Functions deployment. That result belongs in support case 2609160040009134 verbatim. If it also returns 500, the cause is still reproducible from the repository and configuration, so continue with the next tests.
2. Minimal api/ scaffolding. Reduce host.json and api/package.json to known-good minimal versions from a fresh Azure Functions Node.js v4 project, keeping only ping. Both files are app-wide inputs to Functions startup. host.json controls host-level configuration, including the host schema version and extension configuration. package.json supplies the Node application metadata, dependencies, and, in the v4 programming model, the main entry point used to locate and register the functions. A bad entry point, incompatible module mode, missing runtime dependency, or invalid or incompatible host configuration can therefore affect the whole Functions app even when the remaining handler itself has no dependencies. If you previously experimented with Node-version settings, also remove any leftover engines setting for this test so the package metadata is reduced to the minimum rather than carrying an additional build and deployment variable.
3. Static Web Apps configuration. Temporarily reduce staticwebapp.config.json to the platform.apiRuntime block from @Allan Solomon Mejia answer and nothing else, then redeploy and test /api/ping again. This removes the remaining Static Web Apps application-level configuration from the experiment, including any route authorization or redirect rules that could apply to /api/*. If the behavior changes, staticwebapp.config.json is participating in the failure path and its sections can then be restored one at a time.

One thing I could not tell from your updates: has Application Insights been enabled on the Static Web App yet? Logs for managed Functions are only available if Application Insights is enabled. If it is enabled, query the requests, exceptions, and traces tables for the exact test window while sending several requests to the preview hostname.

If those requests produce the empty 500 while FunctionHits remains at zero and no corresponding Function request appears in Application Insights, that is strong evidence for support that the failure occurs before a normal invocation reaches the managed Functions workload.

I would run the new-resource test first because it changes none of the repository contents. If that resource returns 200 immediately, there is little value in modifying host.json, package.json, or staticwebapp.config.json until Microsoft has seen that A/B result.

If the replacement resource works and you need production restored quickly, moving the required application settings and custom domain to the working resource can be handled separately from the platform investigation.

Drafted with help from Claude, disclosed per the Q&A AI usage policy. The isolation sequence is diagnostic procedure rather than documented Azure Static Web Apps behavior; the configuration points above are based on the documented scope of host.json, the Node.js v4 package.json entry point, Static Web Apps configuration, and managed-Functions monitoring.

Hi Fabian,

Quick update on isolation testing. We built a minimal, unlinked test page that calls our existing /api/create-payment-intentfunction directly on the production resource — completely bypassing Stripe Elements, the donation form, and all front-end code. A single button POSTs a hardcoded $25 test amount straight to the function and displays the raw HTTP response.

Result: identical failure signature to the ping isolation test — HTTP 500, Content-Length: 0, empty body, no exception, no stack trace.

This rules out a few more possibilities on our end:

• Stripe Elements or any front-end integration code
• Anything specific to our donation form or its logic
• Our function's own code throwing an unhandled exception — that would return a body/stack trace and would register in FunctionErrors, which it does not

At this point we've isolated the failure down to: any request to any function in this app, on this resource, returns an empty 500 before our code executes, with zero corresponding telemetry in FunctionHits or FunctionErrors.

To confirm — Application Insights is still not enabled on our resource, so we don't have requests/exceptions/traces data to query as you suggested. Would enabling it now still be useful for diagnosing this, or is there another way to get server-side visibility into what's happening before the request reaches our code?

Happy to run anything else that would help narrow this down further.

Thanks!