You deployed your Next.js app on Vercel. Something is broken. A user reports a blank page, or your Stripe webhook is returning 500s, or checkout is mysteriously slow. Your first instinct: check the logs.

Vercel has logging. But once you start relying on it in production, you quickly discover what it can and cannot do. This guide covers how Vercel's logging actually works, how to get the most out of it, and where you need something else.

How Vercel Logging Works

Vercel provides three types of logs:

1. Build logs

Output from next build (or whatever your build command is). These show compilation results, static generation, route analysis, and errors during the build process. Build logs are retained for the lifetime of the deployment.

2. Runtime logs (serverless function logs)

These are the logs from your API routes, server-side rendering, and middleware. Any console.log, console.error, or console.warn call in your server-side code appears here. They also include the function invocation metadata: status code, duration, region, and request path.

3. Edge function logs

Logs from middleware and edge functions. These are separate from runtime logs because they execute in a different runtime environment.

Accessing Vercel Logs

Dashboard

Go to your project in the Vercel dashboard, click "Logs" in the sidebar. You will see a real-time log stream that you can filter by:

  • Level: error, warn, info, log
  • Source: build, lambda (serverless), edge, static
  • Status code: 2xx, 3xx, 4xx, 5xx
  • Path: filter by URL path
  • Time range: last 30 minutes, 1 hour, 6 hours, etc.

CLI

# View logs for a specific deployment
vercel logs https://your-app-abc123.vercel.app

# Follow logs in real time
vercel logs --follow

# Filter by output type
vercel logs --output json

REST API

curl -H "Authorization: Bearer YOUR_TOKEN" \
  "https://api.vercel.com/v1/projects/PROJECT_ID/deployments/DEPLOYMENT_ID/events"

Structured Logging in Vercel

Vercel parses JSON output from console.log. If you log structured JSON, it becomes searchable in the dashboard:

// In your API route
export async function POST(request: Request) {
  const start = Date.now()

  try {
    const result = await processOrder(request)

    console.log(JSON.stringify({
      level: 'info',
      message: 'Order processed',
      orderId: result.id,
      duration: Date.now() - start,
      path: '/api/orders',
    }))

    return Response.json(result)
  } catch (error) {
    console.error(JSON.stringify({
      level: 'error',
      message: error.message,
      stack: error.stack,
      path: '/api/orders',
      duration: Date.now() - start,
    }))

    return Response.json({ error: 'Internal error' }, { status: 500 })
  }
}

This approach makes your logs searchable and parseable. But you are still limited by what Vercel's log viewer can do with them.

Vercel Log Drains

Log drains forward your Vercel logs to an external service in real time. Available on Pro and Enterprise plans.

Supported destinations:

  • Datadog: Direct integration. Logs appear in Datadog's log management with Vercel-specific metadata.
  • Axiom: Native integration via Vercel marketplace. Good free tier (500GB/month ingest).
  • Logflare / Supabase: Free tier available. Logs stored in BigQuery.
  • Generic webhook: Send logs to any HTTP endpoint. Useful for custom setups.

Setting up a log drain:

# Via Vercel CLI
vercel integrations add axiom

# Or via the dashboard
# Project Settings > Log Drains > Add Log Drain

Log drains solve the retention problem. But they introduce a new one: now you need to set up dashboards, alerts, and queries in the external tool. That is a non-trivial amount of work.

The Limitations of Vercel Logging

Here is where Vercel's logging falls short for production monitoring:

1. Retention is too short

PlanRuntime Log Retention
Hobby (free)1 hour
Pro ($20/month)1 day
Enterprise3 days

If a bug happened yesterday and you are on the Hobby plan, the logs are gone. Even on Pro, you have 24 hours to notice and investigate. Miss the window and you are debugging blind.

2. No alerting

Vercel logs are passive. You have to go look at them. There is no way to set up an alert that says "notify me on Slack when /api/checkout returns 500 more than 3 times in 5 minutes." If you are not watching the log stream when the error happens, you will not know about it until a user complains.

3. No per-route metrics

You cannot see aggregate metrics per API route. Questions like "What is the P95 response time of /api/search?" or "What is the error rate of /api/payments over the last hour?" require manual log analysis or an external tool.

4. No historical trends

Is your API getting slower over time? Are error rates increasing? Vercel logs show individual events, not trends. You cannot compare this week's performance to last week's.

5. Cold start visibility is limited

Vercel logs show function duration but do not distinguish between cold start time and execution time. A 2000ms function invocation might be 1500ms of cold start and 500ms of actual work, but the log shows 2000ms.

The Practical Gap: Logs Are Not Monitoring

Logs tell you what happened. Monitoring tells you something is happening right now and you need to act.

The gap between Vercel logging and production monitoring looks like this:

NeedVercel LogsMonitoring
See individual request detailsYesYes
Real-time alertingNoYes
Per-route metrics (P95, error rate)NoYes
Historical trendsNo (short retention)Yes
Auto-discovery of all routesNoYes
Works on Hobby plan1 hour retentionYes (independent of plan)

For side projects, Vercel logs are usually sufficient. You check them when something breaks, fix it, move on. For anything that has users depending on it — a SaaS, an e-commerce store, a B2B API — you need the monitoring layer.

Complementing Vercel Logs with Monitoring

You do not need to replace Vercel logs. They are useful for debugging specific requests. What you need is a complementary layer that watches the aggregate and alerts you proactively.

Nurbak Watch is designed specifically for this. It runs inside your Next.js server via the instrumentation.ts hook — five lines of code — and monitors every API route automatically. It works on any Vercel plan because it does not depend on Vercel's logging infrastructure.

// instrumentation.ts
import { initWatch } from '@nurbak/watch'

export function register() {
  initWatch({
    apiKey: process.env.NURBAK_WATCH_KEY,
  })
}

What you get on top of Vercel logs:

  • Per-route response time metrics (P50, P95, P99)
  • Error rate tracking per endpoint
  • Alerts via Slack, email, or WhatsApp in under 10 seconds
  • Auto-discovery of all API routes (no manual configuration)
  • Historical data beyond Vercel's retention limits

$29/month flat, free during beta. Use Vercel logs for debugging. Use monitoring for knowing when to debug.

Related Articles