Vercel Observability now surfaces per-function invocations, duration, error rate, and external API calls directly in the dashboard, enough to retire a basic Datadog or New Relic setup for single-service cost attribution. It does not span functions. Distributed traces and custom-span timing still require piping Vercel’s data out into an external APM, so the practitioner split is blunt: native for cost, external for cross-service latency.
What does Vercel Observability actually expose per function?
Since going generally available on 2024-12-12, Vercel Observability surfaces framework-aware usage metrics at team and project level: Vercel Functions invocations, durations, and error rates, in-function concurrency, External API requests by hostname, Edge Requests by route, Fast Data Transfer, Builds, and ISR caching, per the GA changelog. The functions view drills into per-route and per-function detail, including latency, paths, and the external APIs each function calls.
What makes this genuinely useful for cost work is that Vercel bills Functions on two separate axes, and the native panel can attribute each one independently. The Functions limits docs list the cost line as “Pay for active CPU time and provisioned memory time.” Two axes billed separately is exactly the shape per-function attribution needs. A vendor panel that saw only wall-clock duration would force you to guess the split, and the split is where the money is: a handler that spends most of its wall-clock waiting on an external model call looks cheap on active CPU time but expensive on provisioned memory time, and without per-function attribution you cannot tell a CPU-bound function from one that is just holding memory open while it waits on a third-party API.
The external-API-by-hostname view compounds that value. It lets you attribute cost back to the third-party dependency a function calls, which is the unit finance teams actually want when they ask why a route got expensive. The observable surface is bounded by hard limits the Functions limits docs spell out: 2 GB max memory on Hobby and 4 GB on Pro/Enterprise, a 300s default duration configurable to 800s (generally available on Pro/Ent) with an 1800s extended beta, 1,024 file descriptors shared across concurrent executions, and a single default region (iad1). Observability can only show what the runtime exposes, and the runtime stops at those ceilings.
Where does the free tier end and Observability Plus begin?
The default panel shows per-function and per-event metrics, but path-level latency and breakdown-by-path are Plus-only; granularity is paywalled, not default. The Observability docs state the limitation plainly: “Latency and breakdown by path are only available for Observability Plus users.”
Observability Plus, available on Pro and Enterprise, extends retention to 30 days, opens full access to all data fields and aggregated latency stats, adds Monitoring for advanced querying, and turns on path-level compute analytics, per the GA changelog, which also lists pricing starting at $10/month with pro-rated on-demand usage at $1.20 per million events.
The structural risk is that the same fan-out that makes the dashboard rich also makes it expensive, and the pricing tier that gates path-level latency is the tier that charges by event volume. A team that upgrades Plus to read path latency inherits a meter that grows with every new event type Vercel folds into the panel.
What can’t native metrics do? Traces, custom spans, and cross-service chains?
Native metrics stop at the function boundary. Distributed traces, custom-span timing, and cross-service latency chains are not in the panel, and the gap is structural rather than a missing feature on a roadmap.
An independent comparison from buildmvpfast.com characterizes Vercel’s built-in monitoring as “Speed Insights (Core Web Vitals), Analytics (page views, visitors), Logs (function execution), and Error tracking (basic)” and explicitly calls these “hosting-adjacent monitoring features, not comprehensive observability,” recommending dedicated tools for deeper application monitoring. That framing is the useful corrective to vendor language that treats Observability as an APM replacement. It is not. The native panel can tell you a function was slow and erroring; it cannot tell you which span inside that function’s call graph owned the latency, because the spans are not collected.
A request in a real application rarely lives inside one function. It leaves through a database connection, an external API, an AI Gateway call, and back. When the latency you need to debug lives in that chain, a per-function duration graph tells you the request was slow but not where the time went. That is the case an external APM exists to solve, and it is the case the native panel provably cannot.
How does the Datadog bridge work, and who bills for it?
Distributed tracing across Vercel Functions is delivered through an external APM like Datadog, fed by a Vercel-side data export, not by the native panel. The Datadog integration docs describe the bridge as exposing request counts, 4xx and 5xx HTTP errors, and Vercel Functions performance through Datadog APM. Those overlap the native panel’s per-function counts, which is the point: for metrics, the two surfaces cover the same ground. Anyone paying Datadog purely for those metrics is duplicating what Vercel already shows. Where the two do not overlap is traces.
The log path runs through Vercel’s Log Drains, which Datadog’s integration page references directly: it instructs users to toggle Log Drain on to forward logs from their Vercel apps to Datadog. The bridge to Datadog is therefore not a Datadog-only concern. The data leaves Vercel through a Vercel-native drain, and whether Vercel prices that drain separately is not stated on the integration page. The defensible claim is architectural rather than pricing: routing logs to Datadog adds a Vercel-side mechanism on top of the Datadog subscription.
The practical consequence is a two-bill debugging path. Native Observability answers “is this function expensive, and is it erroring.” Datadog, fed through the drain, answers “where in the cross-service chain did this request spend 900ms.” Teams that need both answers pay both bills, and the drain is the mechanism that connects them.
Native or external: a decision rule for cost vs latency
Use Vercel Observability for per-function cost attribution and basic error and duration health; keep an external APM for cross-service latency debugging. The split maps cleanly onto what each surface can prove, and onto the billing axes each one inherits.
| Capability | Native Observability | External APM (Datadog / New Relic) |
|---|---|---|
| Per-function invocations, duration, error rate | Yes | Yes |
| Path-level latency and breakdown | Plus only | Yes |
| Active-CPU vs provisioned-memory cost split | Yes (native billing axes) | Via ingested metrics |
| External API calls by hostname | Yes | Yes |
| Distributed traces across functions | No | Yes |
| Custom-span timing | No | Yes |
| Cross-service latency chains | No | Yes |
| Extended retention | Plus adds 30-day | Platform-defined |
The cadence argues against treating the current capability line as final. Vercel’s recent changelog (entries dated 23 through 25 June 2026) shows continued investment around the AI Gateway surface, with AI Gateway Requests now a first-class event type in the Observability docs. Every new event type is also new metered volume under the Plus model, so the observable surface area and the bill that tracks it are expanding together. The structural tradeoff, though, is stable: platform-native metrics inherit the platform’s event model and billing axes, which makes them cheap and well-fitted for cost work but bounded by the platform boundary; external APM spans platforms but routes through Vercel-side drains to get there. Native for cost, external for latency is the line that survives the next changelog.
Frequently Asked Questions
Is the Vercel Trace Drain that feeds Datadog distributed traces a free feature?
No. Datadog’s integration page notes the Trace Drain used to pipe distributed traces into Datadog APM is billed by Vercel, separate from your Datadog subscription and separate from the Observability Plus meter. Teams running cross-service tracing pay Vercel for the drain plus Datadog for the APM ingestion.
Which Datadog-collected metrics duplicate Vercel’s native Observability panel?
Datadog’s Vercel integration ingests five named metrics: vercel.functions.invocations, vercel.functions.duration, vercel.functions.errors, vercel.functions.max_memory_used, and vercel.requests. The first four overlap the native panel; max_memory_used is the one signal in that set that goes beyond the duration-and-error view the native panel centers on.
Does Vercel Observability work with Lambda-style instrumentation that reads AWS_ runtime variables?
Not reliably under fluid compute. Vercel’s fluid compute model hides the AWS_* runtime environment variables that Lambda-style introspection depends on, so instrumentation built to read those variables silently misses them. Teams moving from a Lambda APM setup need to re-instrument against Vercel’s runtime rather than port their existing collectors.
How does the AI Gateway event type affect Observability Plus billing?
Each AI Gateway call is its own metered event at $1.20 per million on Plus, on top of the function invocation that triggered it. Vercel’s June 24, 2026 changelog added GLM 5.2 Fast via Wafer to the Gateway, so a route that proxies model traffic now emits two billable events per request, not one.
What does Observability Plus cost for a route doing one million dynamic requests per month?
One million dynamic requests that each fan out into the documented six-event pattern generate roughly six million metered events, or about $7.20 per month at the $1.20-per-million Plus rate, on top of the $10/month base. Routes that also hit the AI Gateway cost more because each model call adds its own metered event.
