Is Vercel down, or is the problem limited to one deployment, custom domain, or network connection? Check Vercel’s official status page first, then compare the affected project with other Vercel-hosted sites to narrow the cause.
Site Administrator
Last reviewed: September 25, 2026
LATEST RECORDED STATUS
Up Vercel’s website appeared to be up and responding normally at the last check.
| Endpoint | Status | Observed |
|---|---|---|
| vercel.com | Operational | 2026-11-09 12:34 UTC |
Is it working for you?
0 recent reports — more reports are needed for a useful trend.
For the full picture, including partial or regional outages a single external check may miss, see Vercel’s official status page. official status page.

Vercel is a cloud and developer platform for deploying and serving web projects. A reported incident on Vercel’s official status page is the strongest initial signal of a broader platform problem, but it does not confirm that every project, domain, or deployment is affected.
A Vercel-wide issue becomes more plausible when unrelated projects, deployments, dashboard actions, or other platform functions fail at approximately the same time. If one project or custom domain fails while the status page shows no matching incident, investigate that deployment’s build output, runtime behavior, environment configuration, DNS, certificate, or redirect settings.
The message shown in a browser can also describe a failure on the path between your device and the requested site. Record the exact error, affected hostname, time of failure, whether another Vercel project works, and whether the same request succeeds from another device or network before changing configuration.
Open Vercel’s official status page and compare any reported incident with the feature that is failing. If the incident matches, note the affected deployment or project and the time of failure, avoid unrelated configuration changes, and retry when the incident information indicates recovery. If no relevant incident is listed, continue with project, domain, and local checks.
Inspect the affected deployment’s build and runtime output. Confirm that the expected deployment is connected to the requested hostname and compare it with a known-working deployment when possible. A failure isolated to one project points more strongly to application code, build settings, environment configuration, or domain setup than to a platform-wide outage.
A custom-domain error does not by itself indicate that Vercel is unavailable. Check recent DNS changes, the records for the requested hostname, and whether the hostname and certificate configuration match. For a redirect loop, test the intended HTTP and HTTPS addresses and review the project’s redirect rules.
Useful related diagnostics include [DNS_PROBE_FINISHED_NXDOMAIN](/guides/dns-probe-finished-nxdomain), [DNS_PROBE_FINISHED_BAD_CONFIG](/guides/dns-probe-finished-bad-config), [ERR_CERT_COMMON_NAME_INVALID](/guides/err-cert-common-name-invalid), and [ERR_TOO_MANY_REDIRECTS](/guides/err-too-many-redirects).
Try the URL in a private window, temporarily disable extensions, and test from another device or network. If it works elsewhere, investigate browser state, local DNS caching, or the original network route before changing the deployment. Connection-refused and connection-timeout messages may originate from the client path or a specific origin request rather than from Vercel as a whole. See [ERR_CONNECTION_REFUSED](/guides/err-connection-refused) and [ERR_CONNECTION_TIMED_OUT](/guides/err-connection-timed-out).
Capture the exact action, requested hostname, timestamp, response status, and error body. Compare the same operation through the dashboard or browser when possible. This helps distinguish authentication or project-configuration problems from build failures, transient network errors, and broader platform incidents. Do not expose deployment credentials or tokens in diagnostic output.
For deployment, domain, project, and account-specific details, consult the relevant Vercel dashboard logs and vendor documentation. A general status result cannot confirm that an individual project’s configuration is correct.
Every time this page loads, our server makes its own request to vercel.com (and its API domain, when applicable) and reports what it got back — a real HTTP response, a timeout, or a connection failure. That result is cached for up to 2 minutes.
This confirms external reachability; it does not test every feature, region, account, or network path. Cross-check the official status page when one is available.
No. This is a live, one-off connectivity check run from our own server, not Vercel's own incident reporting. Their official status page can show partial, regional, or component-level issues our single external check cannot detect.
A basic reachability check confirms that the server responded to our request. It does not test every feature, region, ISP, browser, or account-specific issue.
A check is refreshed after the two-minute cache expires. The displayed check time shows when the observation was made.
Not necessarily. Many services split their website and API onto separate infrastructure, so one can fail while the other keeps working.
Check Vercel’s official status page for reported availability issues. If no relevant incident is listed, determine whether the failure affects multiple projects, one deployment, a custom domain, or only your device and network.
Test another unrelated Vercel-hosted project or deployment that you can access and compare the result with the official status page. Similar failures across unrelated projects are more consistent with a broader service issue than an error isolated to one project.
An HTTP 500 response indicates a server-side failure associated with the request or deployment. Review the deployment’s build and runtime output, check recent application or environment changes, and compare the timing with Vercel’s status page. See the [HTTP 500 troubleshooting guide](/guides/http-500-internal-server-error) for general diagnostic steps.
The domain path can fail independently of overall Vercel availability. Check DNS records, the configured hostname, certificate matching, and redirect behavior. DNS_PROBE_FINISHED_NXDOMAIN, ERR_CERT_COMMON_NAME_INVALID, and ERR_TOO_MANY_REDIRECTS indicate different parts of that path and should be investigated separately.
Test in a private window and check extensions, local DNS caching, and the failing network route. If the same URL works elsewhere, investigate the local connection before changing project or deployment configuration.
Not automatically. First check the official status page and record the affected deployment, timestamp, and error. Repeated redeployments can make it harder to distinguish a platform incident from a project-specific build or runtime problem.
This is a live connectivity check from our server, not an official statement from Vercel. A down result may also reflect a regional or partial outage.