Vercel Tracing GA: When Built-In Wins and When to Keep OpenTelemetry

If your team ships Next.js on Vercel and pays for a self-managed OpenTelemetry Collector or a third-party APM to see traces, the routing decision just changed. Vercel announced that Vercel Tracing is generally available on all plans, and new Next.js 16.5+ projects with at least one Node.js function get tracing turned on automatically after their first successful build. Everything Vercel-side in this article, from the retention numbers to the auto-instrumentation scope, is vendor-claimed from a single changelog and the pricing page; no independent operational evidence was available at writing. That caveat matters, because the honest version of the decision is narrower than the announcement suggests: the built-in pipeline is a good default for a specific envelope of teams, and the Collector stays for everyone whose retention, language, or backend needs fall outside it.

The short answer: if you run Next.js 16.5+ on Node.js functions, your retention needs fit inside 14 days, and an in-product query language covers how your engineers actually debug, the built-in pipeline removes real operational cost. If you need retention past 14 days, instrumentation across non-Next.js services, or traces in a backend you own, none of the GA documentation establishes a route there, so the Collector stays. And if compliance makes you both, you run both, deliberately.

What Vercel actually shipped at GA

Per Vercel’s GA changelog, the feature is span-based distributed tracing with a dashboard and CLI surface: Spans and Traces lists with filtering, search through Kibana Query Language (KQL), and a Live mode that streams new traces as they arrive. The automatic part is tightly scoped:

“Starting with Next.js 16.5, new projects created on Vercel that include at least one Node.js function get tracing turned on after their first successful build.”

On sampling, the changelog states: “Vercel adds one sampling rule tracing 100% of requests in all environments and injects instrumentation at build time, so traces include Next.js framework spans with no setup.”

Three details in that passage carry the decision. First, “new projects” and “Next.js 16.5”: the changelog does not document automatic coverage for existing projects on older framework versions, other frameworks, or non-Node.js runtimes. If your estate is a mix, the auto-enablement story covers only part of it. Second, the changelog’s “100% of requests in all environments” is a generous default for debugging but a cost question against a bundled allowance, which I will come back to. Third, “injected at build time” means the instrumentation is Vercel’s, not yours; you do not control the span taxonomy the way you do with hand-configured OTel SDKs.

Retention increased across every tier between beta and GA, per the same changelog:

“Hobby now keeps traces for 3 days instead of 1 hour, Pro for 14 days instead of 1 day, and Enterprise for 14 days instead of 3 days.”

Note the internal tension: Enterprise equals Pro at 14 days. Upgrading tiers buys you nothing on retention, which tells you where Vercel thinks this feature sits. It is an engineering workflow tool for recent traffic, not an archive.

On pricing, Vercel’s pricing page lists tracing as a bundled platform allowance rather than metered ingest: the Hobby plan includes “1M span units / month included” with “3 days of traces” of retention. What the fetched pricing excerpt does not state is what happens past the allowance: overage terms were not in the evidence, so treat the changelog’s 100% sampling default as a number you need to check against your own request volume before assuming it is free.

The stay-or-move checklist: five axes that actually differ

The announcement framing (“tracing, now included”) obscures that the built-in pipeline and an external OTel pipeline are different products solving overlapping problems. These are the axes where they genuinely diverge, mapped to what is documented versus what only the external option provides.

Two of these rows deserve more than a cell.

Instrumentation breadth. The case for OTel is not abstract. The OpenTelemetry-to-Kieker interoperability paper contrasts Kieker, which instruments “Java, C, Fortran, and Python,” with the OpenTelemetry standard, which “aims for providing reference implementations for most programming languages, including C# and JavaScript.” That breadth is the point: if your traces need to span a Next.js frontend, a Java service, and a Python worker, one parent span with concurrent children completing out of order (the asynchronous trace model the same paper describes), you need instrumentation everywhere, not just where Vercel injects it. A platform pipeline that only sees the Vercel-hosted edge of the request gives you a partial trace and calls it complete.

Backend ownership. The OpenTelemetry Demo case study describes the reference OTel topology as including infrastructure services “such as Jaeger and Prometheus” that you operate yourself. That is the architectural difference in one sentence: the standard OTel pattern assumes you own the telemetry backend, with all the retention control, query depth, and compliance posture that ownership grants, and all the maintenance burden too. A bundled platform pipeline grants none of the control and none of the burden. Which side of that trade you want depends on the next two sections.

When the built-in pipeline wins

The built-in option wins when your workload fits its documented envelope and the thing you are actually short on is time, not traces.

Concretely: a team of three running a Next.js 16.5 application entirely on Vercel, debugging production issues that surface within days, currently either running no tracing at all or paying an APM bill out of proportion to the team’s size. For that team, the marginal cost of observability just dropped to near zero. No Collector to provision, no exporter configuration, no SDK version drift across services, no on-call rotation for the observability stack itself. The first successful build turns it on, the dashboard is where the deployment logs already live, and KQL plus Live mode covers the common debugging loop: find the slow request, expand its spans, see which framework layer or external call ate the time.

The changelog’s 100% default is the right call for this team, too. At low request volumes, sampling below the changelog’s rule of 100% mostly hides the exact rare failures you opened the tracing tool to find. And a million span units a month is a reasonable allowance for a small application’s traffic, though again, what happens past it is not documented in the fetched pricing evidence.

This is the second-order effect worth naming: when tracing ships with the platform, the threshold at which observability justifies its own infrastructure moves up. Teams that would never have staffed a Collector now get traces by default. That is a genuine improvement for the small-team case, and it does not generalize past it.

When the Collector stays

Three conditions keep the external pipeline, and each maps to a gap in the documented GA scope rather than a preference.

Retention past 14 days. Audit trails, incident post-mortems that span quarterly reviews, capacity trend analysis, regulated-industry record-keeping: all of these need trace or span data retained well past two weeks. No Vercel tier, Enterprise included, documents retention beyond 14 days. If your compliance requirement is measured in months or years, the built-in pipeline cannot be your system of record, full stop.

Multi-language, multi-service estates. If the request path crosses services Vercel does not host, the built-in pipeline sees a fragment. OTel’s cross-language reference instrumentation exists precisely for this topology, and a Collector is the standard way to fan one instrumentation effort out to whatever backends you need.

Your own backend. Here I have to be careful, because this is an inference from absence, not a measured negative. No OTLP or third-party export path appears anywhere in the fetched GA documentation. That does not prove export does not exist; it means the evidence I have does not establish it. If routing Vercel traces into your existing Jaeger, Tempo, or vendor APM is a hard requirement, verify export support directly before assuming either answer. If it is absent or limited, the Collector stays.

The hybrid pattern

For teams with compliance or long-retention requirements, the right answer is not a choice but a division of labor: built-in tracing for the daily engineering workflow, the Collector-fed backend as the system of record.

The logic is that the two pipelines serve different consumers with different time horizons. The engineer debugging a failed checkout at 2 p.m. needs the last hours of traces, fast, where they already work; the built-in dashboard with Live mode is good at that. The auditor, the SRE doing quarterly reliability review, the incident review board: they need complete, durable records in a store the organization controls, and that is the Collector’s job. Running both costs less than it sounds, because the built-in side is zero-infrastructure, and the Collector side already exists if you have the compliance requirement that justifies it.

The caveat: whether Vercel traces can be exported into that system of record, or whether the two pipelines run as genuinely separate collection paths, is exactly the undocumented question from the previous section. The hybrid pattern is sound either way, but its architecture depends on the answer. Treat “can I export?” as a verification step in your migration plan, not an assumption.

Cold starts, the sampling default, and the allowance ceiling

One constraint the announcement does not mention: Vercel functions are serverless, and serverless cold starts are a routine, measured operational condition, not an edge case. A 31-day trace of a production serverless platform recorded “85 billion requests and over 11 million cold starts,” and cold-start latency can dominate a request: in a production serverless LLM-serving environment, “a cold-start instance produces the first token after more than 40 seconds, whereas subsequent generation takes only ∼30ms per token.”

To be precise about what this does and does not show: these papers measure workload cold starts, not the cost of Vercel’s build-time-injected instrumentation. No fetched source measures Vercel Tracing’s per-request overhead. What the cold-start evidence does establish is the regime your traces will describe: a latency profile where initialization frequently dwarfs steady-state execution, and where the changelog’s 100% sampling default means every one of those expensive cold starts generates spans that count against your allowance. For a high-traffic application, the interaction between the changelog’s “100% of requests in all environments” and the pricing page’s “1M span units / month included” is a cost question with no documented overage answer. Before you leave the default in place on a busy production project, count your expected span volume and get the overage terms in writing.

What the GA documentation does not establish

The useful discipline with a single-vendor GA announcement is separating what shipped from what the announcement implies. The fetched evidence does not establish:

• An OTLP or third-party export path. Absence here is uncertainty, not proof of absence.
• Overage pricing past the bundled 1M span-unit Hobby allowance.
• Automatic instrumentation coverage for pre-16.5 projects, non-Next.js frameworks, or non-Node.js runtimes.
• Any measurement of tracing overhead on cold starts or warm requests.
• Independently observed reliability or completeness of the GA pipeline.

Each of these is a bounded verification step, not a reason to dismiss the feature. The built-in pipeline is, by its vendor’s own documented scope, a strong default for Next.js-on-Vercel teams with short retention horizons, and the cheapest observability those teams will ever run. The Collector remains infrastructure worth keeping when retention, breadth, or backend ownership is the requirement. If you sit between those poles, run the hybrid and verify the export question first. What the GA changes is the default; it does not change what you actually need to keep.

Frequently Asked Questions

Which Vercel plans include tracing and what are the retention limits?

Hobby now keeps traces for 3 days instead of 1 hour, Pro for 14 days instead of 1 day, and Enterprise for 14 days instead of 3 days.

How much tracing data is included in the Hobby plan?

the Hobby plan includes “1M span units / month included” with “3 days of traces” of retention.

Does Vercel Tracing automatically enable for existing projects?

Starting with Next.js 16.5, new projects created on Vercel that include at least one Node.js function get tracing turned on after their first successful build.