"Production is slow / throwing errors. But I can't tell which route is the cause" — without observability, both failure investigation and cost optimization become guesswork. Vercel comes with multi-layered observability as standard, so you can mechanically trace "from symptom to cause."
This article summarizes each layer of observability and the "measure → optimize" workflow, faithful to the official specs of Vercel Observability. For the full picture, see the Vercel production-operations guide.
The map of observability: five layers
| Layer | What it tells you | Enablement |
|---|---|---|
| Observability (Insights) | Per-route metrics for functions/edge/middleware/external APIs/ISR/image optimization, etc. | Standard (free on all plans) |
| Speed Insights | Real users' CWV (LCP/INP/CLS) | @vercel/speed-insights |
| Web Analytics | Access analytics (cookieless, privacy-conscious) | @vercel/analytics |
| Runtime Logs / Log Drains | Function logs / external forwarding | Standard / Log Drains |
| Monitoring / Notebooks / OTel | Dashboards, alerts, external-APM integration | Observability Plus / OpenTelemetry |
Observability: what's happening per route
The Observability tab visualizes requests along the app's structure. Free on all plans, with Observability Plus (Pro/Ent) adding latency, per-path breakdowns, and long-term retention.
Insights visualized (a subset):
- Vercel Functions: invocation count, error rate, execution time (per route)
- External APIs: latency and failures of external API calls
- Edge Requests / Middleware: edge and middleware behavior
- ISR / Image Optimization / Fast Data Transfer / AI Gateway / Queues / Blob: usage of each feature
Events Vercel tracks: Edge Requests, Function Invocations, External API Requests, Routing Middleware Invocations, AI Gateway Requests. One request can become multiple events (e.g. 1 Edge Request + 1 Middleware + 1 Function + 2 External API = 5 events) — this is also the cost breakdown (cost optimization).
The failure-investigation workflow (don't guess)
①Observability で対象機能（例: Functions）と期間を選ぶ
↓
②Error Rate / Duration のグラフでスパイクを特定、ズームイン
↓
③ルート一覧をエラー率 or 遅延で並べ替え、犯人ルートを特定
↓
④ルートをクリック → Runtime Logs へ直行 → スタックトレース確認
↓
⑤原因を修正（[トラブルシューティング](/blog/vercel-troubleshooting-build-function-errors-timeout-guide) 参照）
Tracing from primary sources — "symptom (error rate, latency) → route → logs → cause" — is the royal road of SRE (principles of observability/SRE).
Speed Insights: real users' Core Web Vitals
Rather than synthetic measurement (Lighthouse), it measures real users' perceived experience (LCP/INP/CLS). Just install @vercel/speed-insights and place the component.
// app/layout.tsx（Next.js App Router）
import { SpeedInsights } from "@vercel/speed-insights/next";
export default function RootLayout({ children }: { children: React.ReactNode }) {
return (
<html lang="ja">
<body>
{children}
<SpeedInsights />
</body>
</html>
);
}
CWV are both a score and a SEO ranking factor. Look at real-user values and improve slow pages with CWV optimization (INP/LCP/CLS).
Web Analytics: cookieless access analytics
With @vercel/analytics, you get privacy-conscious access analytics without relying on cookies. Suited to GDPR-conscious sites.
// app/layout.tsx
import { Analytics } from "@vercel/analytics/next";
export default function RootLayout({ children }: { children: React.ReactNode }) {
return (
<html lang="ja">
<body>
{children}
<Analytics />
</body>
</html>
);
}
A note on both packages: always put
@vercel/speed-insightsand@vercel/analyticsin package.json's dependencies. Installing them globally and referencing them causes build errors, especially in a monorepo (troubleshooting).
Runtime Logs and Log Drains
- Runtime Logs: check functions' and middleware's
console.*output in the dashboard. The primary source for failure investigation. - Log Drains: forward logs to Datadog, Grafana, your own collection platform, etc. For long-term retention, cross-cutting analysis, and integration with existing APM.
Structured logs: rather than
console.log("text"), emitting JSON structured logs that include a correlation ID, route, and user (PII-masked) makes searching and aggregating at the Log Drains destination orders of magnitude easier. Not emitting PII is essential by design.
// 構造化ログの最小形（相関IDで追える）
function log(level: string, msg: string, ctx: Record<string, unknown>) {
console.log(JSON.stringify({ level, msg, ts: Date.now(), ...ctx }));
}
log("info", "order.created", { orderId, region: process.env.VERCEL_REGION });
Monitoring, Notebooks, OpenTelemetry
- Monitoring: build dashboards and alerts on top of metrics.
- Notebooks: save and organize Observability queries.
- OpenTelemetry: with OTel-collector integration, send traces and metrics to external APM. Introduce distributed tracing and you can correlate the chain of Vercel function → external API → DB.
Rolling Releases × external metrics: when you want to make canary decisions in your own APM, propagate the deployment ID to the external observability system. This lets you distinguish canary and base metrics, so you can make the promotion decision for Rolling Releases with your own numbers.
Run "measure → optimize"
Observability isn't "install and done"; it's the starting point of an improvement loop.
| Purpose | Where to look | Next action |
|---|---|---|
| Slow | Speed Insights (CWV) / Functions Duration | CWV optimization, caching |
| Errors | Error Rate → Runtime Logs | Troubleshooting |
| Expensive | Functions Insights (Invocation/Active CPU) | Cost optimization |
| Bots/attacks | Firewall tab | WAF/BotID |
Production checklist (observability)
- Monitor functions, error rate, and latency per route with Observability
- Measure real-user CWV with Speed Insights (directly tied to SEO)
- Cookieless access analytics with Web Analytics
- Put
@vercel/speed-insights/@vercel/analyticsin package.json dependencies - Emit structured logs (JSON, correlation ID, PII masking)
- Integrate with external APM via Log Drains / OpenTelemetry
- Detect budget/failures with Spend Management and alerts
- Run "measure → optimize" as a loop
Summary
Observability isn't "emitting logs"; it's creating a state where you can trace stopped processing, slow pages, and expensive routes at a glance.
- Identify symptoms (errors/latency/cost) per route with Observability
- Real users' experience and behavior with Speed Insights / Web Analytics
- Primary sources and external integration with Runtime Logs / Log Drains
- Distributed tracing with OpenTelemetry, canary comparison with the deployment ID
- Put it all into a "measure → optimize" loop
I take on, as a project, the design of observability (structured logs, SLOs, alerts, external-APM integration, cost monitoring).
This article is based on the Vercel Observability official documentation (as of June 2026). Features and plan conditions are updated, so confirm the latest values officially at production adoption.