Static Web Apps managed Functions deployment exits 1 with Node 22, including minimal health-only API

Troy Foren 0 Reputation points
2026-10-16T23:22:32.1433333+00:00

I am troubleshooting an Azure Static Web Apps managed Azure Functions deployment failure and need help obtaining the underlying server-side error. I have not established an Azure outage or platform fault.

Environment:

  • Static Web Apps Free plan; managed Functions region Central US.
  • Node.js 22 (deployment shell reported 22.23.3) and SWA CLI 2.0.10.
  • Latest failed deployment recorded by the portal: 2026-10-16 22:05:08 UTC.

Observed behavior:

The full application and a minimal health-only Functions reproduction both fail during managed Functions deployment with a generic Azure Functions failure and exit code 1. The same symptom occurred before and after recreating the Static Web App. The latest minimal diagnostic package completed a clean installation of three packages before failing.

Checks completed:

  • Clean dependency installations and package manifests were checked for both the full application and minimal reproduction. Runtime flags were checked against the documented deployment configuration.
  • A real local Azure Functions host successfully discovered the functions. The minimal health endpoint returned HTTP 200. The full application returned its expected HTTP 503 not-configured response without production configuration.
  • ldd on the downloaded StaticSitesClient showed resolved shared libraries, with no not-found entries.
  • The portal Production environment shows Failed but exposes no detailed deployment error or correlation link. The Activity log has no matching failed upload operation. Content Deployment diagnostics remained at analyzing the last 24 hours.

Questions:

  1. How can I retrieve the managed Functions server-side deployment log, inner error, and deployment/correlation ID for this failed upload?
  2. Is there a documented compatibility restriction involving Node 22, SWA CLI 2.0.10, managed Functions, or the Free plan that would explain this result?
  3. What additional sanitized diagnostics would distinguish package validation from managed backend provisioning failure?

I can provide a sanitized minimal reproduction if needed; this post contains no credentials or application data.

Azure Static Web Apps
Azure Static Web Apps

An Azure service that provides streamlined full-stack web app development.

0 comments

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-10-16T23:22:52.45+00:00

    For Azure Static Web Apps managed Functions, the documented places to get more detail are the deployment workflow logs and Application Insights.

    1. To retrieve deployment error details for the upload/build path:
      1. Open the GitHub repository for the static web app.
      2. Select Actions.
      3. Open the failed workflow run.
      4. Open Build and Deploy Job.
      5. Open Build And Deploy and review the log output.
      Azure Static Web Apps documents that build and deployment errors from the Oryx-based workflow are logged there. It also documents folder-validation errors to check specifically:
      • invalid app_location
      • invalid or missing output_location
      • missing or not found API directory
      For managed Functions, the workflow YAML controls the source code folder location for the managed functions app.
    2. To retrieve runtime/server-side errors for managed Functions:
      • Logs are only available if Application Insights is enabled.
      • For managed Functions in Static Web Apps, logging is turned on by enabling Application Insights on the static web app.
      • After Application Insights is installed, runtime failures can be reviewed in Azure portal:
        1. Open the Resource Group for the static web app.
        2. Select the Application Insights instance with the same name as the static web app.
        3. Under Investigate, select Failures.
        4. Use Drill into and open the failed operations.
        5. Select an operation to view the full error message and stack trace.
      Application Insights only shows errors generated after it is installed.
    3. For the specific request for a managed Functions deployment inner error, server-side deployment log, or deployment/correlation ID for the failed upload: No documented method in the provided material exposes a separate managed-Functions backend deployment log, inner error stream, or correlation ID beyond the workflow logs and Application Insights.
    4. For compatibility restrictions that could explain the failure: The documented managed Functions runtime constraints list supported Node.js versions as Node.js 12, 14, 16, 18, and Node.js 20 (preview). Node.js 22 is not listed in the provided managed Functions constraints. That is the only documented compatibility restriction in the provided material relevant to the reported Node.js version. No documented restriction was provided for SWA CLI 2.0.10 or the Free plan causing this exact failure.
    5. Diagnostics that help distinguish package/configuration validation from managed backend issues:
      • If the GitHub workflow log shows folder/configuration errors, focus on app_location, output_location, and api_location.
      • If deployment succeeds but API requests fail, enable Application Insights and inspect Failures for runtime exceptions and stack traces.
      • For TypeScript-based Node Functions, verify:
        • tsconfig.json outDir points to the build output
        • scriptFile points to compiled .js files, not .ts
        • dependencies are installed
      • For Node configuration issues, verify:
        • required environment variables are set in Azure portal Application Settings
        • Application Insights connection string is configured
        • log filtering in host.json

    The strongest documented signal in this case is the runtime-version mismatch: managed Functions constraints in the provided documentation do not include Node.js 22.

    References:

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

    Was this answer helpful?

  2. kagiyama yutaka 5,655 Reputation points
    2026-10-17T03:32:21.09+00:00

    I think Node 22 alone doesn't explain this. Managed Functions supports node:22 on Free, and SWA CLI 2.0.10 supports it too. Local HTTP 200 doesn't validate the deployment package. Compare swa --print-config with the actual deploy command (apiLocation, --env). Also check staticwebapp.config.json (node:22) in the app output. The CLI defaults to preview.

    Retry the minimal deployment with --verbose silly and redact tokens. If the inner error or correlation ID remains unavailable, contact Azure technical support with the sanitized log, minimal repro, resource ID and UTC timestamp. Ask for the failing stage and any available IDs. A support plan is required.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.