Fix Vercel “FUNCTION_INVOCATION_FAILED” 500 errors

FUNCTION_INVOCATION_FAILED

You see this code on Vercel’s 500 page, in the Logs tab next to a red 5xx row, or in a client that got an empty Internal Server Error back from an API route. It can hit one route or every route that imports the same broken module. It often starts right after a deploy that worked fine on your machine.

The code itself says very little. It tells you the function process died before it sent a response. The reason is almost always printed one line above it in your runtime logs, as a stack trace. This page shows how to get to that line fast, and how to fix the four causes that produce it most often.

What FUNCTION_INVOCATION_FAILED means

Vercel’s error reference defines it as a failed function invocation, with status code 500 and the name Internal Server Error. It lists two possible causes:

• The runtime process (Node.js, Bun, Python and so on) crashed.
• Node.js or Bun threw an unhandled rejection or an uncaught exception.

Vercel files it under function errors. The platform did its job: it routed the request to your function and started it. Your code, or the environment it runs in, then failed hard enough to take the process down.

That makes it different from the timeout codes. A function that runs too long fails with FUNCTION_INVOCATION_TIMEOUT and a 504. If that’s what you’re seeing, read how to debug Vercel function timeouts and the guide to the 504 gateway timeout on serverless functions. This page covers crashes only.

When I worked on observability for Workers at Cloudflare, most “the platform returned a 500” reports turned out to be one uncaught throw at module load. The fix starts with reading the right log line, so do that before you change any code.

Finding the crash in Vercel’s runtime logs

Runtime logs hold everything your function writes to stdout and stderr, grouped per request. Open your project, go to Logs in the sidebar, and filter by Status Code 500. Since March 2026, the request details panel also shows the specific error code next to the HTTP status, so you can confirm the row is FUNCTION_INVOCATION_FAILED and not another 500 (changelog).

The CLI does the same from a terminal:

# Production 500s from the last hour, full messages
vercel logs --environment production --status-code 500 --since 1h --expand

# Everything logged for one request
vercel logs --request-id <request-id> --expand

# Only Vercel Function logs, as JSON for jq
vercel logs --source serverless --level error --json | jq '.message'

To get the request ID for a request you made yourself, read the x-vercel-id response header. Vercel’s custom error page docs say the request ID token matches that header’s value.

In the request details, look at three things:

1. Log Messages. The stack trace or error message your runtime printed just before the crash. This names the cause in most cases.
2. Function. The function name, runtime, duration and memory usage for that invocation.
3. Deployment. The deployment ID and branch. If the errors start at one deployment, diff that deployment against the previous one.

Act quickly on older failures. The runtime logs docs keep logs for 1 hour on Hobby, 1 day on Pro and 3 days on Enterprise, or 30 days with Observability Plus.

Cause 1: an uncaught exception or unhandled promise rejection

How to tell it’s yours: the log for the failed request ends with a stack trace from your own code or a library it calls. Typical messages are TypeError: Cannot read properties of undefined, a JSON parse error, or a rejected fetch or database call.

This is the most common cause and the first one in Vercel’s list. An exception that nothing catches ends the process. Promise rejections do the same. The Node.js CLI docs say that since Node.js 15 the default --unhandled-rejections mode is throw: Node emits unhandledRejection, and if no handler is set, it raises the rejection as an uncaught exception. So a single await without error handling, or a promise you fired and forgot, is enough to crash the function.

Fix:

1. Read the top frame of the stack trace that belongs to your code. That’s the line to fix.
2. Wrap the handler body in try/catch, which is the first fix Vercel’s error reference suggests. Log the error with its stack and return a proper error response:

   // app/api/orders/route.ts
   export async function POST(request: Request) {
     try {
       const body = await request.json();
       const order = await createOrder(body);
       return Response.json(order, { status: 201 });
     } catch (err) {
       console.error("POST /api/orders failed", err);
       return Response.json({ error: "Could not create order" }, { status: 500 });
     }
   }

3. Await every promise you start, or attach a .catch() to it. A background call you don’t await can reject after the response logic has moved on:

   // Before: a rejection here has no handler
   sendWelcomeEmail(user);
   
   // After
   sendWelcomeEmail(user).catch((err) => {
     console.error("welcome email failed", err);
   });

4. Add process-level handlers in a module every function imports, so any throw you missed is logged with its stack. Keep them for logging. They don’t replace the fixes above:

   // lib/crash-logging.ts
   process.on("unhandledRejection", (reason) => {
     console.error("unhandledRejection", reason);
   });
   process.on("uncaughtException", (err) => {
     console.error("uncaughtException", err);
   });

5. Validate input before you use it. A request body that’s missing a field is a common source of undefined errors on one route only.

Check for throws at module load too. Code at the top level of a file, such as a client constructor that reads config, runs before your handler. If it throws, every request to that function fails, and a try/catch inside the handler can’t help. Move that setup into a function you call inside the handler, or guard it.

Cause 2: an environment variable that’s missing at runtime

How to tell it’s yours: the stack trace mentions a value that is undefined, an SDK complains that an API key or connection string is missing, or a database client fails to connect with an empty host. It works locally and in one environment, and fails in another.

Vercel scopes each environment variable to Production, Preview or Development, and optionally to a Git branch. A variable that exists in your local .env or only in Preview isn’t there in Production. The environment variables docs also say changes are not applied to previous deployments. They only apply to new ones. So adding the variable fixes nothing until you redeploy.

Fix:

1. List what each environment has:

   vercel env ls production
   vercel env ls preview

   Sensitive values are hidden in this list, which is expected. Check that the name is present and spelled the same way your code reads it.
2. Add or update the missing variable for the right environment:

   vercel env add DATABASE_URL production
   vercel env update DATABASE_URL production

3. Reproduce locally with the exact production set. You can pull it to a file or run a command with it, without writing it to disk:

   vercel env pull .env.production.local --environment=production
   vercel env run -e production -- next build

4. Redeploy so the function gets the new values:

   vercel --prod

5. Fail fast with a clear message. Check required variables when the handler runs, so the log says which one is missing:

   function requireEnv(name: string): string {
     const value = process.env[name];
     if (!value) throw new Error(`Missing environment variable ${name}`);
     return value;
   }

One more limit to know. Vercel allows 64 KB of environment variables in total per deployment, and no single variable can be larger than that. A very large certificate or JSON blob can push you over it.

Cause 3: a file or dependency traced out of the function bundle

How to tell it’s yours: the log shows ENOENT: no such file or directory for a path your code reads, or Cannot find module for a package or a native binary. The same code works with next dev or vercel dev.

At build time, Vercel and Next.js trace which files each function needs and put only those in the bundle. Files read through dynamic paths, templates, fonts, data files and some native binaries can be missed. The Next.js output docs say tracing can fail to include required files, and give outputFileTracingIncludes as the fix.

Fix for Next.js:

1. Add the missing files to the trace for the routes that need them. Keys are route globs and values are file globs from the project root:

   // next.config.js
   module.exports = {
     outputFileTracingIncludes: {
       "/api/report": ["./templates/**/*"],
       "/*": ["./src/config/runtime/**/*.json"],
     },
   };

2. In a monorepo, files outside the Next.js project folder aren’t traced by default. Set outputFileTracingRoot and include them:

   const path = require("path");
   
   module.exports = {
     outputFileTracingRoot: path.join(__dirname, "../../"),
     outputFileTracingIncludes: {
       "/api/report": ["../shared/assets/**/*"],
     },
   };

3. Keep patterns narrow. The Next.js docs warn against **/* at the repo root because it makes oversized traces.

Fix for other frameworks: use includeFiles in the functions block of vercel.json. The vercel.json reference notes that it is not supported in Next.js:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "functions": {
    "api/report.js": {
      "includeFiles": "templates/**"
    }
  }
}

Then redeploy and check the build output. Vercel caps a function bundle at 250 MB uncompressed, or 500 MB for Python, per the functions limits. If adding files pushes you near that, use outputFileTracingExcludes or excludeFiles to drop what the function doesn’t use.

Cause 4: the function runs out of memory

How to tell it’s yours: the request has no useful stack trace, or the log stops mid-work. The Function section of the request details shows memory usage close to the function’s limit. Failures cluster on routes that handle large payloads, images, PDFs or big query results.

Vercel’s knowledge base guide on OOM failures says that when a function hits its memory limit, the runtime terminates it and returns a 500 error. That matches the “runtime process crashed” cause in the error reference.

Fix:

1. Confirm it. Go to Observability, then Vercel Functions, pick the route, and read the Peak memory chart against the provisioned limit. The guide says a function that regularly uses 80 to 90% of its memory is at risk under traffic spikes.
2. Cut the memory the request needs. Stream large responses and files, paginate big queries, and avoid loading a whole upload into memory at once.
3. If the work really needs more, raise the memory. The memory docs say you can’t set memory in vercel.json, and doing so gives a warning at build time. On Pro and Enterprise:
   • Open the project, then Settings, then Functions.
   • Select Advanced Settings.
   • Under Function CPU, switch from Standard (2 GB, 1 vCPU) to Performance (4 GB, 2 vCPUs).
   • Create a new deployment. The change applies only to future deployments.
4. On Hobby, memory is fixed at 2 GB with 1 vCPU, and 2 GB is also the plan’s maximum. Reducing usage is the only fix there, or moving to Pro, where the maximum is 4 GB.

How to confirm FUNCTION_INVOCATION_FAILED is fixed

After the new deployment is live:

1. Call the route that failed and check for a 200 or the status you expect:

   curl -s -o /dev/null -w "%{http_code}\n" https://your-app.vercel.app/api/orders

2. Watch for new 500s on the new deployment:

   vercel logs --environment production --status-code 500 --since 30m --expand

   No new rows with FUNCTION_INVOCATION_FAILED in the request details means the crash is gone.
3. Open Observability, select Vercel Functions, and check the Error Rate graph. Sort the routes by error rate. The route you fixed should be back at its usual baseline.

If the 500s continue but the stack trace changed, you’ve fixed one throw and found the next. Repeat from the logs.

Stopping crashes from coming back

• Keep the logging handlers. unhandledRejection and uncaughtException logging means the next crash arrives with a stack trace.
• Check required environment variables in CI. Run the build with production variables through vercel env run -e production -- <command> so a missing variable fails before deploy.
• Test the deployed bundle. Hit every route on a Preview deployment before promoting it. Missing traced files only show up in the deployed bundle.
• Watch memory before it runs out. Review the Peak memory chart for heavy routes after each release.
• Alert on 5xx spikes. Vercel’s knowledge base guide says Vercel raises an alert when function failures cause a spike in errors on a route. Route those alerts to the channel your on-call reads, and keep your logs long enough to read them.

Tracing FUNCTION_INVOCATION_FAILED to its cause with Polylane

Polylane connects to Vercel with OAuth and can query its logs and metrics, and alerts that fire on a connected Vercel account become issues. A fix run reads the logs, recent deploys and your code, traces the crash to its cause with evidence, and opens a pull request for you to review when a code change fixes it.

Running on Vercel? See how Polylane monitors Vercel in production.