Deploying outputs fails with internal error — zero output artifacts

Help
1

Problem

My Next.js 16.1.6 project builds successfully on Vercel but fails during the “Deploying outputs…” phase with: Error: Unexpected error. Please try again. (). No useful logs, no stack trace.

Current behavior

The build completes every time. Build logs show all 12 pages generated, serverless functions created, and Build Completed in /vercel/output. The failure happens only after that, at the output-deploy step.

npx vercel inspect on the failed deployment shows zero build artifacts:

id       dpl_AdT1LZcWpNqWHjyfvNFiXK6577rf
target   preview
status   Error
Builds
  - .    [0ms]

A successful build in /vercel/output but an empty Builds record (0ms, no artifacts) points to the output-upload step failing on the platform side rather than in my code.

Environment

  • Framework: Next.js 16.1.6 (App Router)
  • Plan: Hobby
  • Node: 22.x
  • Function Region: iad1
  • Fluid Compute: enabled
  • Stack: Supabase + Cloudflare R2

What I’ve verified / ruled out

  • npm run build passes locally, clean (TypeScript OK, all 12 pages generated)
  • No middleware.ts or proxy.ts in the repository — verified with git ls-files (only third-party matches inside node_modules)
  • No residual Firebase imports (grep clean in app/ and lib/)
  • Deploying via npx vercel CLI — same error
  • Redeploy without build cache — same error
  • As isolation tests I briefly tried Function Region gru1 and Fluid Compute disabled — same failure, so I reverted both to the defaults above
  • Persists 12+ hours across many retries, including a cold retry the next day

Detail: the main branch (deployed ~2 months ago) works fine in production. Only new deployments from my current feature branch (migracion/supabase) fail. Same repo, same account.

Failed deployment ID: dpl_AdT1LZcWpNqWHjyfvNFiXK6577rf
URL: scanivo-3m4xnzsjx-sebastianspr344-projects.vercel.app

Is this a known platform-side issue right now? The empty Builds record / zero output artifacts pattern suggests the failure is on the deploy infrastructure. Happy to provide more deployment IDs. Thanks.

2

Update — found the actual root cause with a local vercel build run, since
the dashboard gives no diagnostic detail at all. I want to be upfront that I
can’t be 100% certain this is a Vercel-side issue, but I’ve run out of
angles to test on my end. Cross-posting from a parallel thread I have going
with Amy (Vercel team) on r/vercel:
Reddit - Please wait for verification — flagging here too in case
this forum gets more visibility with your infra team.

The real error (never surfaces in the dashboard)

Running npx vercel build locally exposes the actual internal failure:

Error: Unable to find lambda for route: /dashboard/perfil
code: “NEXT_MISSING_LAMBDA”

Full stack trace from .vercel/output/builds.json:

at …/node_modules/@vercel/next/dist/index.js:12940:13
at …/node_modules/@vercel/next/dist/index.js:15614:18
at Array.map ()
at serverBuild (…/node_modules/@vercel/next/dist/index.js:15613:49)

Next.js itself compiles and traces this route without any error — the
.nft.json file exists and is valid, and the build output correctly shows:

├ ○ /dashboard/perfil (Static)
├ ƒ /dashboard/[id] (Dynamic)

The failure happens strictly inside @vercel/next’s lambda-grouping step,
after Next.js has already finished successfully. .vercel/output/functions/
is never created — the process dies before writing a single output
artifact. This matches the “empty Builds record / zero artifacts” pattern I
flagged in my original post above.

100% reproducible locally

Ran the identical build 3 times with zero code changes: same error, same
route, every time.

I fixed it — and the error moved to a completely unrelated route

Theory at the time: a static leaf (/dashboard/perfil, ○) next to a
dynamic sibling (/dashboard/[id], ƒ) under the same path was confusing
the lambda grouping. Added a scoped app/(admin)/dashboard/layout.tsx with
export const dynamic = "force-dynamic" to force the whole subtree dynamic.

Result: /dashboard/perfil correctly flipped ○ → ƒ. Next.js compiled
clean. Build still failed — same error code, now on a structurally
unrelated route:

Error: Unable to find lambda for route: /menu/[localId]
code: “NEXT_MISSING_LAMBDA”

This route has zero static siblings in conflict. It’s a standalone SSG
route:

export const revalidate = false;
export const dynamicParams = true;
generateStaticParams() → returns (params resolved from a database at
request time, standard on-demand ISR pattern)

This is inconsistent with my original theory — fixing the reported
occurrence relocated the failure instead of resolving it.

Cross-checked against Next.js 15.5.20

To rule out a Next 16-specific cause, I downgraded to next@15.5.20 (latest
stable 15.x) with zero code changes and re-ran the build. Identical
failure, same route, same internal error code. Same builder, same result
across two major Next.js versions — points away from a Next-version-specific
cause and toward @vercel/next itself. Reverted back to 16.1.6 afterward.

Everything else already ruled out (see original post above for full list)

Middleware, vercel.json, stale deps, route naming collisions, --prebuilt,
the build-queue incident (confirmed resolved, retried, same failure),
project-level config (reproduced identically on a brand-new isolated
project with zero Git integration). A structurally similar production
branch deploys clean in under 2 minutes against that same new project,
ruling out account/CLI as the cause too.

Same pattern reported by others, unresolved

Several independently report the affected route changing between build
attempts — consistent with what I saw after my fix relocated it.

I could be missing something on my end, but I’ve genuinely run out of
things to test locally. Happy to share the full builds.json output or the
exact commit hash that fails 100% of the time. Repo is private (real client
data), but glad to share any specific file/config on request.

3

Solved — root cause found and fix confirmed in production.

Following up on the update above: I moved the investigation into an
isolated, from-scratch repro to get a clean signal without the noise of a
real production codebase.

Method: additive bisection, one variable per commit, real cloud deploy at
every step (local builds never reproduce this — only actual Vercel deploys
count). I rebuilt the real project’s structure piece by piece — route tree,
DB clients, UI library, file storage SDK, PDF generation, all dependencies
installed and used exactly as in the real app — and every step deployed
cleanly (Ready) until I added the last cluster of real files. That’s where
it broke, with the same “Deploying outputs…” failure / empty Builds
record described above.

From that failing state, reverse bisection:

  1. Isolated the failure down to one file: a Client Component importing 6
    Server Actions from a sibling actions.ts
  2. Swapped those 6 imports for plain functions (same names, no
    "use server") → deploy succeeded. Confirmed: the Server Actions
    themselves are the trigger.
  3. Restored as 6 real Server Actions in one file → failed again
  4. Split across 3 separate "use server" files → still failed — so it’s
    not about file count or organization
  5. Consolidated into a SINGLE exported Server Action (a dispatcher
    function) that internally routes to 6 private, non-exported functions
    → deploy succeeded

Minimal shape that reproduces it:

// actions.ts (“use server”)
export async function actionOne() { /* … / }
export async function actionTwo() { / … / }
export async function actionThree() { / … */ }
// …6 exported Server Actions total

// page.tsx (“use client”)
import { actionOne, actionTwo, actionThree, /* …6 total */ } from “./actions”;

→ fails (“Deploying outputs…” / NEXT_MISSING_LAMBDA / empty Builds
record, zero output artifacts)

Fix that worked:

// actions.ts — consolidated: only ONE exported action, routing internally
async function actionOne() { /* … / } // no longer exported
async function actionTwo() { / … / }
async function actionThree() { / … */ }

export async function runAction(input: { type: string; payload: any }) {
switch (input.type) {
case “one”: return actionOne();
case “two”: return actionTwo();
case “three”: return actionThree();
}
}

→ deploys clean

Root cause (as far as I can isolate without access to @vercel/next
internals): a Client Component importing more than one individually
exported Server Action makes the builder fail silently at the
output-deploy stage. Doesn’t depend on file count, code size, dependencies,
or Next.js version — reproduced identically on 16.1.6 and 15.5.20.

Fix: replace N exported Server Actions consumed by the same Client
Component with ONE exported dispatcher (e.g. export async function runAction(action: { type: string; ...payload })) that switches internally
to private functions. Applied this to the real project — deployed
successfully for the first time after weeks of identical failures on every
push. Stable in production since.

Posting the full writeup in case it saves someone else the same
investigation. I have an isolated repro project (public package, no client
data) that demonstrates this end to end — happy to share it privately if
it’d help your team dig further.