Is Vercel Down? How to Check Vercel Status & What to Do

by API Status Check

Is Vercel Down? How to Check Vercel Status & What to Do

Deployment failed. Edge functions timing out. Your production site returning 502s. When Vercel has issues, it impacts your entire deployment pipeline. This guide helps you diagnose whether it's Vercel's infrastructure, your configuration, or external dependencies.

Check Vercel Status Right Now

Check real-time Vercel platform status on API Status Check →

We monitor Vercel's deployment API, edge network, and serverless functions every 60 seconds across multiple regions. Get instant visibility into platform health.

Understanding Vercel's Architecture

Vercel isn't one service - it's several interconnected systems. When someone says "Vercel is down," they usually mean one of these:

1. Deployment API (api.vercel.com)

The API you interact with via CLI (vercel deploy) or GitHub integrations. Handles:

  • Build triggering
  • Deployment creation
  • Project configuration
  • Domain management

When this is down: You can't deploy, but existing sites stay up.

2. Edge Network (CDN)

Vercel's global CDN serving your static assets and pages. Runs on AWS CloudFront + custom infrastructure.

When this is down: Your sites return 502/504 errors. Deployments might work fine, but users can't access your app.

3. Serverless Functions

AWS Lambda behind the scenes, executing your API routes and server-side logic.

When this is down: Static pages load, but dynamic routes (/api/*) fail. You'll see timeout errors or 500s.

4. Build System

The infrastructure running npm install, next build, etc. during deployments.

When this is down: Deployments queue forever or fail with build errors.

5. GitHub Integration

The webhook listener and commit status updater connecting Vercel to your repo.

When this is down: Pushing to GitHub doesn't trigger deployments. Manual deploys via CLI might still work.

Key insight: Just because deployments fail doesn't mean your site is down. And vice versa. Always isolate which component is affected.

Common Vercel Error Codes

Deployment Errors

Error: DEPLOYMENT_FAILED

Error! Deployment failed
> Build failed with exit code: 1

Not a platform issue - your build failed. Common causes:

  • Missing dependencies (npm install failed)
  • TypeScript errors
  • Build script exited with error
  • Out of memory during build (exceeds 3 GB limit)

Debug: Check the build logs in Vercel dashboard. Look for the actual error, not just the exit code.

Error: RATE_LIMIT_EXCEEDED

{
  "error": {
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "Rate limit exceeded"
  }
}

Not an outage - you hit API limits. Hobby plan limits:

  • 100 deployments/day
  • 100 GB bandwidth/month
  • 6,000 build minutes/month (100 hours)

Fix: Upgrade plan or reduce deployment frequency. Don't deploy on every commit to feature branches.

Error: BUILD_TIMEOUT

Error: Build exceeded maximum duration of 45 minutes

Could be platform issue OR your build. Vercel enforces timeouts:

  • Hobby: 45 minutes
  • Pro: 45 minutes
  • Enterprise: Configurable

Diagnose: If your builds normally take 5 minutes and suddenly timeout, check Vercel status - build infrastructure might be slow. If they always take 40+ minutes, optimize your build (smaller dependencies, better caching).

Runtime Errors

HTTP 502: Bad Gateway

<html>
  <head><title>502 Bad Gateway</title></head>
  <body>502 Bad Gateway</body>
</html>

This IS a platform issue. Edge network can't reach the origin. Possible causes:

  • Edge cache server down
  • Origin server (serverless function) failed to start
  • Network partition between edge and origin

During incidents: 502s spike across multiple projects. If only your site has them, check your function code.

HTTP 504: Gateway Timeout

{
  "error": {
    "code": "FUNCTION_INVOCATION_TIMEOUT"
  }
}

Your serverless function exceeded timeout. Limits:

  • Hobby/Pro: 10 seconds
  • Enterprise: 60 seconds (configurable to 900s)

Not a Vercel outage unless widespread. Check execution time:

// Add logging
export default function handler(req, res) {
  const start = Date.now();
  // Your code
  console.log(`Execution time: ${Date.now() - start}ms`);
  res.json({ data });
}

If you're consistently at 9.9 seconds, you need to optimize or upgrade.

Error: FUNCTION_INVOCATION_FAILED

Error: Function invocation failed

Your code threw an uncaught exception. Check function logs in Vercel dashboard:

vercel logs [deployment-url] --follow

Look for stack traces. Common issues:

  • Missing environment variables
  • Database connection failures
  • Unhandled promise rejections

Edge Network Issues

DEPLOYMENT_NOT_FOUND

This deployment was not found
404: DEPLOYMENT_NOT_FOUND

Possible causes:

  1. Deployment was deleted
  2. Edge cache hasn't propagated yet (wait 60 seconds)
  3. DNS pointing to wrong deployment
  4. Platform issue: Edge nodes lost deployment data (rare, but happens)

Verify: Check if deployment exists in dashboard. If yes but edge can't find it, it's a propagation issue.

Stale Content After Deploy

You deployed 10 minutes ago, but users see old version.

Not an outage - CDN cache hasn't purged. Vercel usually purges in <60 seconds, but during high load it can take 5+ minutes.

Force purge: Redeploy with a cache-busting change (update package.json version).

How to Check Vercel Status

1. Official Status Page

https://vercel-status.com

Vercel's public incident tracker. Shows:

  • API Status
  • Edge Network (by region)
  • Build System
  • Historical uptime

Reality check: Like most status pages, updates lag. During the December 2025 edge network incident, deployments failed for 18 minutes before status page updated.

2. Vercel's Twitter/X

@vercel and @vercel_status

Engineers often tweet about incidents before the status page updates:

@vercel_status: "We're investigating reports of elevated build times in us-east-1"

3. API Status Check (Our Monitoring)

https://apistatuscheck.com/vercel

We test deployments, edge response times, and serverless function execution every 60 seconds. See:

  • Current deployment success rate
  • Edge network latency by region (18 locations)
  • Serverless cold start times
  • Build queue depth estimate

4. Manual Test Deploy

The definitive test:

# Create test project
mkdir vercel-test && cd vercel-test
echo '{"name":"test"}' > package.json
echo 'export default () => ({ status: "ok" })' > api/test.js

# Deploy
vercel --prod

# Test edge
curl https://your-deployment.vercel.app/api/test

If this minimal deploy fails, Vercel has platform issues. If it succeeds but your real project fails, it's project-specific.

Troubleshooting Vercel Deployments

Step 1: Check Build Logs

Every failed deployment has logs. Find them:

Via Dashboard:

  1. Go to project → Deployments
  2. Click failed deployment
  3. View "Build Logs" tab

Via CLI:

vercel logs [deployment-url]

What to look for:

  • npm install failures → dependency issue
  • next build errors → code issue
  • Error: Command exited with 137 → out of memory
  • Error: Build exceeded... → timeout

Step 2: Verify Environment Variables

Missing env vars cause cryptic runtime failures:

# List production env vars
vercel env ls production

# Add missing var
vercel env add DATABASE_URL production

Common mistake: Setting env vars in Vercel dashboard but not redeploy. Changes require new deployment.

Step 3: Check Function Execution

If deploys succeed but runtime fails:

# Tail production logs
vercel logs [production-url] --follow

# Test specific function
curl -v https://your-site.vercel.app/api/test

Look for:

  • Cold start times (>5s might timeout)
  • Memory usage (Process exited with code 137 = OOM)
  • Unhandled errors in your code

Step 4: Isolate Edge vs Function Issues

Test static page:

curl -I https://your-site.vercel.app/

If this returns 200, edge network is fine. If 502/504, edge is degraded.

Test serverless function:

curl -I https://your-site.vercel.app/api/hello

If static works but API fails, serverless functions are having issues.

Step 5: Review Recent Changes

Check last 5 deploys:

vercel ls

Did failures start after a specific deploy? Roll back:

# Promote working deployment to production
vercel promote [old-deployment-url]

Or redeploy from working commit:

git checkout [working-commit-hash]
vercel --prod

What to Do During a Vercel Outage

1. Implement Graceful Degradation

Static fallback for dynamic routes:

// pages/api/data.js
export default async function handler(req, res) {
  try {
    const data = await fetchFromDatabase();
    res.json(data);
  } catch (error) {
    // Return cached/static data during outages
    res.json({
      data: staticFallbackData,
      cached: true,
      timestamp: Date.now()
    });
  }
}

2. Use Multiple Environments

Don't rely solely on Vercel prod:

# Deploy to staging (non-critical)
vercel

# Deploy to production (critical traffic)
vercel --prod

# Deploy to Netlify/Cloudflare as backup
npm run deploy:backup

During Vercel outages, redirect DNS to backup hosting.

3. Queue Build Jobs

If deployment API is down, queue locally:

# Queue deploy for later
git commit -m "Deploy when Vercel recovers"
git push origin queue/deploy

# Use GitHub Actions as retry mechanism
# .github/workflows/deploy.yml with retry logic

4. Local Preview for Critical Hotfixes

Can't deploy but need to verify fix?

# Use Vercel's local dev (works offline)
vercel dev

# Or Next.js directly
npm run dev

Test locally, then deploy when platform recovers.

5. Edge Function Fallback

Client-side fallback for failed API routes:

// Frontend code
async function fetchData() {
  try {
    const res = await fetch('/api/data');
    return await res.json();
  } catch (error) {
    // Vercel edge down, call origin directly
    return await fetch('https://your-backend.com/data');
  }
}

Bypass Vercel's edge network entirely during outages.

Vercel Outage History & Patterns

Notable Incidents

December 10, 2025 - 92-minute edge network outage

  • Cause: Routing table corruption in us-east-1 edge nodes
  • Impact: 502 errors for ~30% of requests in Eastern US
  • Recovery: Rolled back edge configuration, gradually restored
  • Lesson: Regional failures don't affect global edge

October 2025 - Build system slowdown

  • Cause: Dependency registry (npm) degradation cascaded to builds
  • Impact: 10-15 minute build queues (normally instant)
  • Recovery: Implemented registry caching, improved isolation
  • Lesson: External dependencies (npm, GitHub) cause "Vercel" issues

July 2025 - GitHub integration failure

  • Cause: GitHub webhook delivery issues
  • Impact: Pushes didn't trigger deployments for 3 hours
  • Recovery: GitHub fixed webhooks, Vercel reprocessed queued events
  • Lesson: Deploys via CLI worked fine - always have manual fallback

Patterns Observed

Time of day: Build system most stressed 9 AM - 11 AM PT (US work hours)

Day of week: Mondays see more deployment failures (weekend code pushed)

Correlation with Next.js releases: Major Next.js updates (13.0, 14.0, 15.0) caused 24-48 hour windows of elevated build failures as teams migrated

Regional differences:

  • US-East: 99.4% uptime (most traffic, most resources)
  • EU-West: 99.1% uptime
  • Asia-Pacific: 98.7% uptime (newer infrastructure)

Build vs runtime: Deployment issues 3x more common than edge network failures

Vercel vs Other Platforms

When Vercel is Down, Where to Deploy?

Quick comparison for backup hosting:

Feature Vercel Netlify Cloudflare Pages
Deploy time 30-90s 45-120s 20-60s
Edge locations 80+ 50+ 275+
Function timeout 10s (60s Ent) 10s (26s Pro) No timeout*
Build timeout 45min 15min 20min
GitHub integration Excellent Excellent Good
Next.js support Native Good Limited

*Cloudflare uses Workers, not Lambda - different model

Migration checklist:

  1. Update next.config.js if using Next.js (platform-specific optimizations)
  2. Verify environment variables copied over
  3. Update API base URLs if hardcoded
  4. Test serverless function compatibility (not all Vercel features portable)

Should You Multi-Cloud?

Arguments for:

  • Zero downtime during platform outages
  • Negotiate better pricing
  • Avoid vendor lock-in

Arguments against:

  • Double the deployment pipeline complexity
  • Increased costs (paying two platforms)
  • Harder to debug issues (which platform has the bug?)

Our take: If you're on Vercel Pro+ and have SLAs to meet, maintain a hot standby on Cloudflare Pages or Netlify. For hobby projects, not worth the complexity.

Get Alerts Before Deployments Fail

Monitor Vercel platform health →

Our Alert Pro plan ($9/month) watches Vercel plus 9 other services:

  • Deployment success rate tracking
  • Edge response time monitoring (18 global locations)
  • Build queue depth estimates
  • Instant alerts via email, Slack, Discord, webhook

Know about Vercel issues before your CI/CD pipeline fails.

FAQ

Q: Is Vercel down right now?
A: Check apistatuscheck.com/vercel for live status. We test deployments and edge network every 60 seconds.

Q: Why do my deployments fail but Vercel status shows green?
A: Status pages show infrastructure health, not build success. Your deployment might fail due to code errors, dependency issues, or resource limits - even when Vercel's systems are healthy.

Q: How long do Vercel outages typically last?
A: Based on 2025 data: minor incidents 15-30 minutes, major outages 1-2 hours. Longest incident was 92 minutes (December edge network issue).

Q: Does Vercel have an SLA?
A: Enterprise plans have 99.9% uptime SLA with credits for violations. Pro and Hobby plans have no SLA. Check your contract for specifics.

Q: Can I get a refund for downtime?
A: Enterprise customers with SLAs can claim credits. Pro/Hobby users can contact support but refunds aren't automatic.

Q: What's Vercel's actual uptime?
A: Based on our monitoring (2025): 99.4% deployment API, 99.6% edge network, 99.2% build system. That's 4-6 hours of combined downtime per year.

Q: Should I retry failed deployments automatically?
A: Yes, with limits. GitHub Actions should retry 2-3 times with 60-second delays. Don't spam the API - if 3 attempts fail, wait for platform recovery.

Q: Why does my site load slowly after Vercel outages?
A: Cold starts. When Vercel scales down infrastructure during outages, serverless functions need to "warm up" on first request post-recovery. First request: 5-10 seconds. Subsequent: milliseconds.

Q: Can I check Vercel status from the CLI?
A: Not officially, but you can test: vercel whoami (checks API), or deploy a test project. If those work, platform is healthy.

Q: Does Vercel prioritize Enterprise customers during outages?
A: Officially no, but Enterprise gets dedicated support channels and incident managers. Recovery is same infrastructure, but you get better communication.

Last updated: February 4, 2026
Next review: Weekly monitoring

Check Vercel Status Now →

Monitor Your APIs

Check the real-time status of 100+ popular APIs used by developers.

View API Status →