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

Question

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

MLU 20

Problem description

I am experiencing an issue with my Azure Static Web Apps where API routes return an empty HTTP 500 error, and no functions are being invoked. Despite the deployment appearing successful, the API endpoints do not respond as expected.

Environment

Azure Static Web Apps, Serverless API hosting, in the Central US region.

What I've already tried

I have ruled out CORS issues, missing environment variables, routing configuration problems, and have confirmed in GitHub Actions logs that the build and deployment completed successfully. I also verified that the api/ping.js function is fully self-contained and returns a hardcoded 200 response, with no shared bootstrap, secrets validation, or database clients involved. I already have an open Developer-tier support request (2609160040009134) on this issue, and the AI-driven support responses so far have not resolved it. I'm posting here as instructed by the support portal in order to continue receiving assistance on the case.

Current status

Currently, I have not confirmed a service-side cause. I am seeking guidance on how to diagnose this further, specifically how to inspect the deployed API package and configuration, or how to force the managed API build to use Node.js 18 instead of the current Node.js 22.22.0, to resolve the issue.

0 comments

2 answers

Your answer

Answer 1

Allan Solomon Mejia 8,840

Hello @MLU

Based on what you've already tested, I agree this doesn't look like a normal CORS, application-setting, or function-code failure. If even a minimal HTTP function returning a hardcoded 200 produces an empty 500 without the function being invoked, the failure is likely occurring before your handler executes.

One clarification: Do not try to force Node.js 18. Node 18 reached end of support for Azure Static Web Apps managed APIs on May 31, 2025. The currently supported Node runtimes are Node 20 and Node 22.

You can explicitly select the managed API runtime in staticwebapp.config.json:

{
  "platform": {
    "apiRuntime": "node:20"
  }
}

platform.apiRuntime is the supported way to select the runtime for managed Functions.

One thing worth checking carefully is where that file ends up after the frontend build. When there is a build step, staticwebapp.config.json must be copied to the root of the deployed output_location. Otherwise, the deployment can succeed while the platform configuration you expect isn't actually being applied.

Therefore, test node:20, confirm from the GitHub Actions output/artifact that staticwebapp.config.json is present in the deployed output root, and redeploy.

Also enable Application Insights on the Static Web App if you haven't already. Application Insights is the logging mechanism for managed Functions. If /api/* still returns an empty 500 and no function invocation appears there, that's useful evidence that the request is failing in the managed API/runtime layer before your code executes.

Since you already have support request 2609160040009134, I'd add the Node 20 test and the absence of any Function invocation/telemetry to that case. If the same minimal function fails after explicitly selecting a supported runtime, don't keep changing the application code. The managed API deployment/runtime needs investigation.

References:

Configure Azure Static Web Apps - API runtime

API support in Azure Static Web Apps with Azure Functions

Static Web Apps build configuration

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
MLU 20 Reputation points

2026-09-18T18:21:56.75+00:00
Thanks again, Allan — the APIs blade check you pointed me to turned out to be one of the most useful diagnostics in this whole investigation. Clicking into "(managed)" under Backend Resource Name for the PR #3 environment showed the Backend Details panel listing all three functions (create-payment-intent, ping, update-payment-intent) as properly registered — which ruled out function-discovery/registration as the cause entirely.

Since then I've run two more isolated tests to keep narrowing this down:

Pinned the managed API runtime to Node 20 via platform.apiRuntime in staticwebapp.config.json (confirmed via the build log that Node 20 was actually used this time, unlike my earlier failed attempt via package.json). No change — /api/pingstill returns HTTP 500, content-length: 0.

Temporarily removed both Stripe-dependent functions from the deployment, leaving only the zero-dependency pingfunction (a hardcoded 200 responder, no imports at all). Deploy succeeded. Still HTTP 500, content-length: 0.

So at this point: functions are registered (thanks to your check), the Node version isn't it, and even a function with zero code paths that could fail still returns an empty 500. Combined with the Metrics blade showing zero FunctionHits resource-wide despite real test traffic, this really does look like a fault in the managed Functions host itself for this Static Web App resource, rather than anything in the app. I've sent the same findings to Microsoft support directly on the open case (2609160040009134) as well.
Allan Solomon Mejia 8,840 Reputation points

2026-09-18T19:00:59.1733333+00:00

Hi @MLU

Please let me know if you need any further assistance. Otherwise, if the information provided helped/resolved your issue, please click “Accept Answer” to help others who may encounter the same problem.
MLU 20 Reputation points

2026-09-18T19:07:11.0366667+00:00

Thanks, Allan — still open, unfortunately. To summarize where things stand: I've now ruled out the Node runtime version and the two Stripe-dependent functions as causes (details in my update above), which points to a platform-side fault in the managed Functions host itself. I've also escalated this directly on the Microsoft support case (2609160040009134), requesting it go to a Support Escalation Manager, since this no longer looks like something further app-level debugging can resolve. I'll follow up here once I hear back from support or find anything new.

Answer 2

Fabian Zankl 185

Hi @MLU ,

Your managed API on Azure Static Web Apps returns an empty HTTP 500 for every route, no function is ever invoked, and the build and deploy steps in GitHub Actions report success. You have already ruled out CORS, application settings, routing rules and the function body itself (a self-contained api/ping.js returning a fixed 200).

Before anything else, could you share the exact contents of api/package.json (in particular the main and dependencies fields and whether a type field is present) and the folder layout of api/, including whether a host.json and any function.json files exist? Those two things tell us which programming model the host should be loading and rule the registration failures below in or out.

Why a self-contained function can still fail before it runs

Everything you have checked so far sits downstream of function invocation. A 500 with no invocation indicates a failure before your handler runs. One important possibility is that the Functions host discovered zero functions, or failed while loading them. In that state the function body is never reached, so its content is irrelevant to the symptom.

The Node.js worker supports two programming models and they discover functions differently:

v3 model (file-based): one folder per function containing a function.json; the code is expected in index.js in the same folder unless scriptFile points elsewhere. This is the default when @azure/functions is not listed in package.json.
v4 model (code-centric): @azure/functions 4.x is listed under dependencies (not devDependencies), and the main field in package.json names the file or glob that calls app.http(...) to register the function. The migration guide states that host.json and package.json must be at the API root and that the main field must be defined.

A single file at api/ping.js is not sufficient on its own. Under v3 it needs a corresponding function.json, which the host looks for at api/ping/function.json. Under v4 it must be covered by the main entry in package.json and register the function with app.http(...); if main is missing, or points somewhere else, ping.js is never required and app.http is never called. The two models also cannot be mixed: as soon as one v4 function registers, any function.json files are ignored.

Two further variants produce the same outcome and are worth checking in the same pass:

A module load error in a file loaded through main (a wrong import path, a missing dependency, a "type": "module" in package.json combined with require or module.exports) can prevent the affected registration code, and potentially the registration of every function in the app, from completing. A Q&A thread from 2023 (404 static web app azure function TS) describes exactly this: the asker found a wrong import at the top of one API file, and no handlers were registered as a result. Treat this as a pattern to verify against your own code rather than an established platform rule.
Every external package the deployed API requires must be available at runtime, normally by being listed under dependencies in api/package.json, unless your build bundles it into the output. A package that resolves only locally (a workspace package, a global install) is missing at runtime; a 2022 Q&A thread (Azure Static Web App with Managed Functions cannot find module) shows the resulting "Cannot find module" failure for a monorepo setup.

How to confirm it from the portal

For managed functions the documentation directs you to Application Insights for runtime logs; logs are only available once Application Insights is added. Before that, two portal views can provide clues about whether the managed API was detected successfully:

In the Static Web App resource, the APIs blade shows one row per environment with the columns Backend Type and Backend Resource Name. When the platform detected a managed functions app, Backend Type reads "Managed" for the Production environment (as described in the 2022 Q&A thread Azure Static Web App not getting response from static web api API Function); when nothing was detected, both columns show a dash. If Production shows no managed backend even though the deployment was supposed to contain api/ping.js, that is additional evidence that the managed Functions app was not detected or registered. Treat the portal state as a diagnostic clue, not as a documented statement about the exact failure stage.
Users report that the Application Insights blade shows "Add a function to your app to enable App Insights" when zero functions were detected. Treat that as an indicator, not a documented diagnostic contract. The same reports describe this combination, no functions listed while the Diagnose and solve problems blade still counts backend 5xx errors, as the typical signature of a function app that fails to index (Azure/static-web-apps issue #1731, and the Q&A thread StaticWebApp build/deploy job runs successfully but APIs/managed functions are not deployed correctly). Those are user observations, not documented behavior, but they match what you describe.

Reproducing locally

The Static Web Apps CLI runs your API through Azure Functions Core Tools and proxies /api the same way the service does; see Set up local development for Azure Static Web Apps for swa start with --api-location. Core Tools startup output normally shows the functions it discovered and often exposes module-loading or indexing errors that are otherwise hard to see in the managed environment. That output is the closest substitute for the host log you cannot see in Azure.

On forcing Node.js 18

@Allan Solomon Mejia answer already covers this: node:18 is out of support since May 31, 2025 per the supported runtimes table, and platform.apiRuntime in staticwebapp.config.json selects between node:20 and node:22. The point about the config file having to land in the deployed output root is worth checking as well. Switching between 20 and 22 is a legitimate test, but a registration problem of the kind described above persists across both, so if the node:20 test changes nothing, api/package.json and the folder layout are the next place to look.

References

Drafted with help from Claude, disclosed per the Q&A AI usage policy. All technical claims checked against the Azure Functions Node.js developer reference, the Node.js v4 migration guide, and the Azure Static Web Apps documentation on API support, supported runtimes and local development.

MLU 20 Reputation points

2026-09-18T03:35:01+00:00

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?
Fabian Zankl 185 Reputation points

2026-09-18T04:03:47.8433333+00:00
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:

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.

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.
MLU 20 Reputation points

2026-09-18T18:18:13.2733333+00:00

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.
Fabian Zankl 185 Reputation points

2026-09-18T19:13:51.9566667+00:00
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.

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.

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.

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.
MLU 20 Reputation points

2026-09-19T03:07:39.6733333+00:00
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!
Fabian Zankl 185 Reputation points

2026-09-19T04:51:20.07+00:00
Hi @MLU ,

Yes, enable Application Insights now. For managed Functions it is the documented logging surface, and logs are only available once it is added. Send a small batch of requests with recorded timestamps and inspect the raw requests, traces, and exceptions tables for that window rather than the Failures blade. Two outcomes, both useful:

Host- or function-level entries appear for the window. Then you finally have server-side visibility, and a startup, indexing, or entry-point error may name the cause directly.

Nothing appears while the requests keep returning the empty 500. That is evidence that the failure is not being observed through the normal instrumented Functions invocation path, and it belongs in the support case together with the timestamps and the continuing FunctionHits = 0.

One correction to the isolation reasoning: an empty body does not rule out an unhandled exception in the function, because a deployed Functions app does not need to return a stack trace to the caller. The stronger evidence is what you already have: the same empty 500 for the zero-dependency ping, FunctionHits at zero, FunctionErrors unchanged.

A useful control test: deploy the same api/ folder as a normal Azure Functions app on Node 20 with the same host.json and package.json, and call /api/ping on that hostname. It gives you the regular Functions diagnostics for its plan, and a 200 there is another strong indication that the repository is not the differentiating variable. On a Static Web Apps plan that supports bring-your-own backends, such as Standard or Dedicated, that Functions app can then be linked as the Static Web App's backend instead of the managed API, after setting api_location to an empty string in the workflow.

The new-resource test from my previous comment is still the cleanest A/B check you have not run: same repository, same commit, second Static Web App, /api/ping on its default hostname. Application Insights first, since it may expose the cause immediately; then that.

Drafted with help from Claude, disclosed per the Q&A AI usage policy. Diagnostic conclusions are inferences from the observed metrics and telemetry; Application Insights as the logging surface for managed Functions and bring-your-own Functions on Standard and Dedicated plans are documented.