# Vercel status

> Is Vercel down? Live status, uptime history, and per-region response times for Vercel's edge, measured by our own probes rather than user reports.

Published: 2026-08-19 | Canonical: https://yoping.me/status/vercel

## How we check Vercel

We watch vercel.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

Vercel serves its own site from the same edge network that serves its customers' sites, so a plain request to it exercises the delivery path your deployment actually depends on. A dashboard or API health route would tell you whether Vercel's control plane is answering, which is a different question from whether visitors can load what you deployed.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/vercel. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## What is Vercel?

Vercel hosts front ends. A project pushed to a git branch is built,
deployed to a global edge network, and served from whichever location is
closest to each visitor, with serverless and edge functions handling the
dynamic parts. For a large number of teams this replaces both the web
server and the deployment pipeline, which means a Vercel incident can
take out the shipping process and the live site in the same stroke,
though rarely at the same moment.

The distinction between those two halves is the most useful thing to
understand before an incident. The control plane covers builds,
deployments, the dashboard, and the API. The data plane is the edge that
answers visitor requests. When the control plane is degraded you cannot
deploy, promote, or roll back, and the dashboard may be unreachable, but
the site your visitors see keeps working, because it was already
deployed and is being served from infrastructure that does not need the
dashboard to function. When the data plane is degraded the reverse
happens, and there is nothing useful to do in the dashboard at all. Teams
that treat "Vercel is down" as one condition tend to reach for the wrong
remedy, most often triggering a redeploy during an edge incident, which
achieves nothing and occasionally makes the rollback path worse.

The second thing worth knowing is how rarely a broken Vercel site is
actually Vercel's fault. Because the platform absorbs so much of the
build and deploy process, its failure modes and your own arrive through
the same door. A build that failed silently leaves the previous
deployment serving, so the site looks fine while your latest changes are
missing. A missing environment variable in the production scope produces
runtime errors that never appeared in preview. A function that exceeds
its timeout under real traffic passes every local test. All of these
present as "the site is broken" and none of them will show on any status
page, ours or Vercel's.

Geography is the third complication. Edge delivery means a visitor in
Frankfurt and a visitor in Singapore are served by different
infrastructure, and a degradation in one region is invisible from the
other. A single check from a single location cannot distinguish "the
platform is fine" from "the platform is fine where I happen to be
testing from", which is why the regional readings above are shown
separately rather than averaged into one number. When a customer in one
country reports a site that will not load and everyone on your team sees
it working, that split is usually the explanation.

## Frequently asked questions

### Is Vercel down right now?

Check the board above; it reflects our own probes against Vercel's edge from all five of our regions, refreshed every couple of minutes. A failure in one region alone does not make this page say down, a second region has to agree.

### My site on Vercel is down but the status page says everything is operational. What should I check?

Check your own deployment first, because most Vercel-hosted outages are not Vercel outages. A build that failed and left the previous deployment live, a serverless function throwing on cold start, an environment variable missing in production, or a domain whose DNS was changed will all take your site down while Vercel's platform is entirely healthy. The deployment log for the current production deployment is the fastest place to tell those apart.

### Does a Vercel incident affect already-deployed sites or only new deploys?

It depends which part is degraded, and the difference matters. Build and deployment problems stop you shipping while leaving the live site serving normally from cache and the edge. Edge network problems do the opposite, and nothing you can do in the dashboard helps, because the path between visitors and your content is the part that is broken.

### Why is my Vercel site slow in one country but fast in another?

Because content is served from the edge location nearest each visitor, so a regional problem shows up for some visitors and not others. Compare the per-region response times above rather than the single overall verdict; that split is exactly what a one-location check would miss, and it is also what makes complaints from a single office or country plausible even when your own testing looks fine.

### Do serverless function errors show up on this page?

No. This page measures whether Vercel's edge responds to a request, not whether your functions run correctly. A function returning a 500 on every invocation is your code or your configuration, and it will not move the numbers above at all. Your Vercel runtime logs are the right place for that.