Vercel status

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.

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.