Vercel Outage: Platform Errors vs Your Function Errors, and How to Detect Them

Failure facts checked on the vendor’s docs on Nov 8, 2026.

Vercel runs your code, your routing and your CDN. When users see a 5xx, the cause can be Vercel, your function, or something your function calls. The error code in the log tells you which, if you capture it.

Read the error code name

Vercel's error reference has two lists. Application errors come from your deployment or its inputs. Platform errors are Vercel's own, and their names start with INTERNAL_, for example INTERNAL_FUNCTION_SERVICE_UNAVAILABLE, INTERNAL_DEPLOYMENT_FETCH_FAILED and INTERNAL_UNEXPECTED_ERROR.

The 5xx codes you will meet most often are these:

• FUNCTION_INVOCATION_FAILED (500): the runtime process crashed or hit an unhandled exception. This is yours.
• FUNCTION_INVOCATION_TIMEOUT (504): the function ran longer than its allowed duration. Vercel tells you to check the APIs and databases it calls, which makes this the code through which another vendor's outage reaches you.
• FUNCTION_THROTTLED (503): the default concurrency limit was reached, 30,000 for Pro and 100,000 for Enterprise. Vercel notes that rising execution time per request is a sign that capacity is fully used.
• ROUTER_EXTERNAL_TARGET_ERROR (502): a rewrite to an external target failed or did not answer within 120 seconds.
• INTERNAL_*: Vercel lists these as platform errors, so treat them as the platform until proven otherwise.

Example: telling them apart

This is an example, not output from a real project.

2026-11-08T16:02:11Z route=/api/checkout status=504 code=FUNCTION_INVOCATION_TIMEOUT ms=300000 region=iad1
2026-11-08T16:02:14Z route=/api/checkout status=504 code=FUNCTION_INVOCATION_TIMEOUT ms=300000 region=iad1
2026-11-08T16:02:15Z route=/ status=500 code=INTERNAL_FUNCTION_SERVICE_UNAVAILABLE ms=40 region=fra1

The first two lines are timeouts on one route. Look at what /api/checkout calls. The third is a platform code on a different route and region. Two different problems can sit in the same window, and only the code name separates them.

What to log

Vercel's runtime logs are the source, so capture these fields on every request that returns 5xx: route, status, the error code name, duration, region and deployment ID. Group by code name, not by status. Counting only 500s mixes your crashes with Vercel's.

For calls your functions make, log the upstream vendor and its status as well. A burst of FUNCTION_INVOCATION_TIMEOUT with slow upstream calls is your dependency, not Vercel. See third-party failure monitoring.

Thresholds to start with

Compare against the same hour on previous weeks so a traffic peak is not read as an incident.

How Vercel tells you

The Vercel status page splits the platform into components: Functions, Builds, DNS, Routing Middleware, the npm registry and individual CDN regions such as IAD1 and FRA1. Check the component for your function region, not the headline summary. Vercel also offers its own alert rules for error anomalies, on 5xx by default, which complement your own logs.

One failure, two layers

An outage at another vendor often arrives as a Vercel error. If your checkout function calls a payment API that hangs, the user sees a 504 from your Vercel deployment, and the Vercel status page stays green because Vercel is fine. Log the upstream call separately from the function result so you can see that the timeout started one hop away.

During the incident

1. Turn on a custom error page for platform 5xx, so visitors see your branding and a status link instead of a generic error. Vercel supports this.
2. Confirm the code names before opening a ticket, and include request IDs.
3. If upstream calls are the cause, shorten timeouts so functions fail fast rather than reaching the duration limit.
4. Record the start and end times for your postmortem.

Checklist

• 5xx logs include the error code name and region.
• Alerts split INTERNAL_* from application codes.
• Concurrency is watched before it reaches the limit.
• A custom 5xx page is deployed.

More context: vendor degradation detection and Vercel with Sazabi. Sazabi watches the same 5xx shares per route and opens an investigated issue when they climb.