How to Monitor Vercel with Native Tools (CLI, Log Drains, Rollbacks)

Three CLI commands answer most Vercel incidents faster than any amount of dashboard clicking. vercel ls tells you what shipped and when, vercel inspect tells you why a deployment failed, and vercel logs tells you what production is doing right now. If you learn nothing else from this post, learn those three. They turn "the site is down, someone check Vercel" into a two-minute diagnosis.

Part one of this series mapped what actually goes wrong (failed builds, env var drift, function errors, cache surprises, bill spikes) and where each signal shows up. This part is the hands-on layer: DIY Vercel monitoring and triage using only what Vercel ships, meaning the CLI, log drains, rollbacks, webhooks and spend controls. Every command is copy-pasteable. Budget an afternoon to wire it all up. Part three covers the layer that sits on top.

We'll go tool by tool, in the order you'd reach for them during a real incident.

01Tool 1

CLI

ls, inspect and logs: what shipped, why it failed, what prod is doing.

02Tool 2

Rollback

Repoint production at a known-good deployment in seconds.

03Tool 3

Log drains

Ship every log line somewhere it outlives the retention window.

04Tool 4

Webhooks

Deployment events pushed to you instead of polled.

05Tool 5

Spend alerts

A dollar threshold that tells you before the invoice does.

---

Tool 1: The Vercel CLI, deployment inspection

Install and authenticate once (CLI docs):

npm i -g vercel
vercel login
vercel link   # run inside your repo to bind it to the Vercel project

Step 1: Establish what's actually deployed

vercel ls my-app
vercel ls my-app --environment production

The output lists recent deployments with age, URL, status (Ready, Error, Building, Queued) and who triggered them. During an incident this is your first move: did something ship right before the symptoms started? If the newest production deployment is minutes old and the 500s are minutes old, you probably already have your suspect.

Step 2: Interrogate a failed or suspicious deployment

# Full metadata: state, creator, build duration, regions, aliases
vercel inspect https://my-app-abc123.vercel.app

# The build logs, where failed deployments explain themselves
vercel inspect https://my-app-abc123.vercel.app --logs

# Block until a deployment finishes (useful in CI)
vercel inspect https://my-app-abc123.vercel.app --wait --timeout 10m

For a failed build, --logs gives you the same output as the dashboard's build log view, greppable in your terminal. The three most common culprits from part one are a compile or type error in the commit, a missing or stale environment variable (build passes locally, fails on Vercel), and a dependency install failure. All three show up in the last 50 lines of build output.

Step 3: Tail runtime logs during a 500 spike

# Follow runtime logs live for a deployment (passing a URL auto-follows)
vercel logs my-app.vercel.app

# JSON output, filtered to errors only
vercel logs my-app.vercel.app --json | jq 'select(.level == "error")'

# Just the 5xx requests, with path and message
vercel logs my-app.vercel.app --json \
  | jq 'select(.responseStatusCode >= 500) | {path: .requestPath, status: .responseStatusCode, msg: .message}'

Two things to know about vercel logs (docs). Passing a deployment URL follows the stream live, each invocation for up to five minutes, while running it bare in a linked project queries request logs from the last 24 hours. And it only shows runtime output (function invocations, edge requests, console output), not build logs. Beyond that, the dashboard's runtime logs view keeps one hour of logs on Hobby, one day on Pro and three days on Enterprise, or 30 days with the Observability Plus add-on (runtime logs docs). That retention window is exactly why Tool 3 exists.

Tool 2: Rollback and promote, recovery in one command

When step 1 shows a fresh deployment and step 3 shows it throwing errors, you don't debug in production. You revert first (rollback docs):

# Revert production to the previous deployment
vercel rollback

# Or revert to a specific known-good deployment
vercel rollback https://my-app-xyz789.vercel.app

Rollback repoints your production domain at an existing immutable deployment. There's no rebuild, so it completes in seconds. The inverse is vercel promote, which takes any existing deployment (say, a preview build that's already been checked) and makes it production:

vercel promote https://my-app-def456.vercel.app

When the failure was transient (a flaky dependency registry, a build timeout), rebuild the same commit without touching git:

vercel redeploy https://my-app-abc123.vercel.app

A useful habit: after any rollback, run vercel ls again and confirm the production alias points where you think it does. Rollbacks pause automatic promotion of new deployments until you explicitly promote or redeploy, which is easy to forget mid-incident.

Tool 3: Log drains, logs that outlive the retention window

Native runtime log retention is fine for "what's happening now" and useless for "what happened Tuesday". Log drains fix that by shipping every log line to an external store as it's produced.

Setup is in the dashboard: Team Settings → Log Drains → Add Log Drain (Pro and Enterprise plans). You choose:

• Sources: build logs, function (runtime) logs, edge logs, external rewrites. Take at least function and build.
• Delivery format: JSON or NDJSON for a custom endpoint, or syslog.
• Destination: your own HTTPS endpoint, or a one-click integration (Datadog, Axiom, Grafana Cloud, Better Stack and others from the integrations marketplace).
• Environments and sampling: production only or previews too. Sample if volume is a cost concern.

If you point a drain at your own endpoint, verify the x-vercel-signature header (an HMAC of the raw body using your drain's secret) before trusting the payload.

Once logs land in a queryable store, the questions from part one become answerable after the fact: which routes threw 500s between 02:00 and 02:15, whether cold-start latency got worse after a deployment, which function is burning GB-hours. Without a drain, if you didn't have vercel logs running when the incident happened, that data may simply be gone.

Tool 4: Webhooks, deployment events pushed to you

Polling vercel ls doesn't scale past one project. Webhooks push deployment lifecycle events to any HTTPS endpoint: Team Settings → Webhooks → Create Webhook, then pick the projects and events. The events that matter for monitoring:

• deployment.created: something started building
• deployment.succeeded: build finished and passed
• deployment.error: build or check failed
• deployment.canceled: superseded or manually stopped
• deployment.promoted: a deployment became production

The minimum useful setup is deployment.error and deployment.promoted wired to a Slack-posting endpoint. You learn about every failed build without watching CI, and every production change is announced with its commit SHA and author (both are in the payload under the deployment's git metadata). Verify authenticity the same way as drains: compute an HMAC (SHA-1) of the raw request body with your webhook secret and compare it with the x-vercel-signature header:

echo -n "$RAW_BODY" | openssl dgst -sha1 -hmac "$WEBHOOK_SECRET"

Preview deployments are a monitoring tool in their own right. Every PR gets an isolated URL, preview comments let reviewers flag issues on the rendered page, and any checks you've attached run before promotion. Most deployment errors that reach production were visible on a preview URL nobody opened.

Tool 5: Spend management, the bill spike alarm

Part one covered how a traffic spike (or an ISR misconfiguration, or a fetch loop) becomes a bill spike. The native guardrail is Spend Management: Team Settings → Billing → Spend Management on Pro plans. Set a monthly spend amount and Vercel notifies you as usage crosses 50%, 75% and 100% of it, and, if you turn it on, automatically pauses your projects at 100%.

Two honest notes. First, auto-pause takes your site down on purpose. For most production teams the right setting is notifications on, auto-pause off, with the 75% alert treated as a page. Second, spend alerts fire on dollars, not causes. Check the Usage tab (per-project function invocations, edge requests, data transfer) to find which project and metric moved, then line it up with recent deployments using the tools above.

---

One failure through the native stack

It's 02:10 and the Slack channel your webhook feeds shows deployment.error for storefront, production target, commit 9f2e1c. Before anyone touches anything, there are three reasonable readings.

01Reading 1

Code error

A type or import error in the new commit. Fails the same way on every retry.

02Reading 2

Missing variable

A key the build reads exists in Preview but not in Production.

03Reading 3

Transient

A registry hiccup or timeout. The same commit passes on redeploy.

Each has a check.

A code error fails at compile time with a file and line. Read the end of the build log:

vercel inspect https://storefront-9f2e1c.vercel.app --logs 2>&1 | tail -40

A Type error: or Module not found: line naming a file the commit touched settles it.

A missing variable fails while the build reads config, usually with an undefined value during prerendering. If the log names a key, check it exists for the target environment:

vercel env ls production | grep -i STRIPE
vercel env ls preview | grep -i STRIPE

A transient failure shows registry errors (ETIMEDOUT, 503 from the package registry) or a build timeout, and no code in the trace. Redeploy the same commit and see if it passes:

vercel redeploy https://storefront-9f2e1c.vercel.app

Tonight the log ended in Module not found: Can't resolve '@/lib/pricing', and the commit had renamed pricing.ts to price-rules.ts without updating one import in checkout/page.tsx. Reading one. Production was never affected, because the failed build never promoted. The fix is a one-line commit in the morning.

The webhook got the alert to the right place in under a second. Everything after that, including deciding which of the three readings to test first, was a person with a terminal.

---

What each native tool solves, and what it leaves

01Webhooks and alerts

Alert

Tell you a build failed or spend crossed a line, within seconds.

02CLI and drains

Expose

Put every log line and deployment detail one command away.

03Still manual

Correlate

Joining the error, the deployment and the commit, then picking the fix.

---

Where the DIY setup stops

Run everything in this post and you'll have a solid native monitoring setup: real-time triage through the CLI, durable logs through drains, push notifications through webhooks, one-command recovery and a spend tripwire. Build all of it. Also be clear about what it doesn't do.

Everything here notifies. Nothing investigates. A deployment.error webhook tells you a build failed. It doesn't tell you it failed because Tuesday's commit renamed an env var that was never updated in Production. A 500 spike in your drained logs is a line on a chart until an engineer runs vercel ls, compares timestamps, reads vercel inspect --logs and connects them.

Correlation is manual, every time. The core triage move (this error started with that deployment, which contained this commit) is the one step no native tool performs. Logs live in one place, deployment history in another, git blame in a third. The person is the join.

It's reactive by design. Webhooks fire after the failure. Spend alerts fire after the spend. Nothing watches for the pattern forming: error rates creeping after a deploy that "succeeded", cold starts getting worse over a week.

The 3 a.m. problem is untouched. Every tool above assumes an engineer at a keyboard. The setup shortens triage from an hour to minutes, but it never takes the engineer out of the loop.

The approval question you'll meet again

Rollback is the one write in this post that you'd happily run half-asleep, and that instinct is worth writing down. Part three draws the same line: the agent investigates and proposes, and every rollback, promote or env change goes through Auto Mode, so you decide what runs on its own and what waits for approval.

---

What comes next

The manual loop (see the alert, find the deployment, read the logs, find the commit, roll back) is mechanical enough to hand off. Part three covers exactly that: CloudThinker connected to Vercel with a read-only token, watching deployments and runtime errors, tracing a 500 spike to the deploy and commit behind it, and proposing the rollback for your approval instead of paging you to work it out.

To try it on your own project first:

"The last production build for storefront failed. Read the build log, tell me whether it's a code error, a missing variable or a transient failure, and name the commit if it's code. Propose only, change nothing."

Try CloudThinker free with 100 premium credits and no card required.