Describe the bug
A GitHub Actions deploy of a Next.js (App Router) managed-functions app to Azure Static Web Apps consistently fails at the managed-functions activation step. The Oryx build and artifact upload both succeed; Azure's post-upload deployment poll then fails after ~15s with:
Status: Failed. Time: 15.3s
Deployment Failed :(
Deployment Failure Reason: Failed to deploy the Azure Functions.
There is no further diagnostic in the GitHub Actions log, and the portal's SWA deployment detector only lists the failed deployments (Managed Function Language = node 22) and refers back to the GitHub Actions logs. We cannot locate the underlying activation error anywhere we have access to.
Environment
- Action:
Azure/static-web-apps-deploy@v1, action: upload, app_location: /, output_location: "", app_build_command: npm run build
- Framework: Next.js 16 (App Router), hybrid (static + server/SSR + 6
/api/* managed functions)
- Runtime: Oryx detects Node 22.x; Managed Function Language node 22
- Build step log (succeeds):
Repackaged Next.js app to deploy on the backend. → Finished building function app with Oryx → Finished Upload. Polling on deployment.
Symptom timeline (UTC, all push-triggered to the same SWA)
| Time |
Commit |
Result |
| 14:55 |
A |
success |
| 16:25 |
B |
fail |
| 16:59 |
C |
fail |
| 17:27 |
D |
fail |
| 17:41 |
A (re-run of the 14:55 commit) |
success |
| 17:48–17:53 |
D, 3 retry attempts |
fail ×3 |
- Identical failure signature every time: upload OK →
Status: Failed after ~15–22s → "Failed to deploy the Azure Functions."
- Successful deploys poll for ~90s before
Status: Succeeded; failures fast-reject at ~15s.
- We wrapped the deploy step in 3 retries; all three attempts of the same commit failed identically — so it is not a transient single-call timeout.
What we ruled out (comparing the last-passing commit A vs the first-failing commit B)
- No dependency change —
package.json / package-lock.json identical.
- No config change —
next.config.ts, staticwebapp.config.json identical.
- No new routes / functions — identical route manifest: 29 routes, same 6
/api/* managed functions.
- No meaningful bundle difference — built both commits locally; both produce
.next/server = 27 MB, 216 files; total server bytes differ by ~8 KB (~0.2%), entirely from a few small source edits.
- App builds cleanly (
next build exit 0) and runs correctly in local dev. The failure is only at managed-functions activation, after a successful upload.
SWA CLI does not reproduce (different deploy path)
Tried swa deploy (CLI 2.0.9) with --verbose=silly as a local repro. The CLI takes a different path than the GitHub Action — it Skipping step to build .next with Oryx, treats the output as static content, and looks for an index.html, rather than running the managed-Next.js Oryx repackaging the Action uses. It also defaults FUNCTION_LANGUAGE_VERSION: 16 vs node 22 in the Action. So the CLI cannot exercise the failing Oryx managed-functions flow.
Expected behavior
Either the deploy succeeds (as it does intermittently / on other commits), or the "Failed to deploy the Azure Functions" error surfaces an actionable reason (which function, what limit, what validation) somewhere accessible to the developer.
Questions
- Where can we see the actual activation error behind "Failed to deploy the Azure Functions"? It is absent from the Actions log and the portal detector.
- Is there a size / count / shape limit on the packaged managed-functions payload that a Next.js App Router app can intermittently exceed, and how can we inspect the rejected payload?
- Was there a platform-side change/incident to managed-functions activation around 2026-06-01 16:00 UTC? A commit that deployed fine earlier now also fails on re-run, which points away from our code.
Happy to provide the full raw deploy log and the resource details privately.
Describe the bug
A GitHub Actions deploy of a Next.js (App Router) managed-functions app to Azure Static Web Apps consistently fails at the managed-functions activation step. The Oryx build and artifact upload both succeed; Azure's post-upload deployment poll then fails after ~15s with:
There is no further diagnostic in the GitHub Actions log, and the portal's SWA deployment detector only lists the failed deployments (Managed Function Language = node 22) and refers back to the GitHub Actions logs. We cannot locate the underlying activation error anywhere we have access to.
Environment
Azure/static-web-apps-deploy@v1,action: upload,app_location: /,output_location: "",app_build_command: npm run build/api/*managed functions)Repackaged Next.js app to deploy on the backend.→Finished building function app with Oryx→Finished Upload. Polling on deployment.Symptom timeline (UTC, all
push-triggered to the same SWA)Status: Failedafter ~15–22s → "Failed to deploy the Azure Functions."Status: Succeeded; failures fast-reject at ~15s.What we ruled out (comparing the last-passing commit A vs the first-failing commit B)
package.json/package-lock.jsonidentical.next.config.ts,staticwebapp.config.jsonidentical./api/*managed functions..next/server= 27 MB, 216 files; total server bytes differ by ~8 KB (~0.2%), entirely from a few small source edits.next buildexit 0) and runs correctly in local dev. The failure is only at managed-functions activation, after a successful upload.SWA CLI does not reproduce (different deploy path)
Tried
swa deploy(CLI 2.0.9) with--verbose=sillyas a local repro. The CLI takes a different path than the GitHub Action — itSkipping step to build .next with Oryx, treats the output as static content, and looks for anindex.html, rather than running the managed-Next.js Oryx repackaging the Action uses. It also defaultsFUNCTION_LANGUAGE_VERSION: 16vs node 22 in the Action. So the CLI cannot exercise the failing Oryx managed-functions flow.Expected behavior
Either the deploy succeeds (as it does intermittently / on other commits), or the "Failed to deploy the Azure Functions" error surfaces an actionable reason (which function, what limit, what validation) somewhere accessible to the developer.
Questions
Happy to provide the full raw deploy log and the resource details privately.