Operational realityA trace shows the spans that were collected. It does not prove that every important request, business decision or private attribute is represented safely.
Vercel Tracing is generally available on every plan
Vercel's November 6 changelog confirms general availability on Hobby, Pro and Enterprise. Pricing is unchanged from the beta.
The dedicated Traces page lists traces or spans for one project or a whole team. KQL searches attributes such as span name and duration.
A product team investigating a slow checkout can search for database spans above 500 milliseconds, open one request and see which step consumed the time. That is more useful than scrolling through unrelated log lines.
| Capability | Now available | Decision for the team |
|---|---|---|
| Search | KQL across traces and spans in the dashboard | Agree useful fields and saved incident queries |
| CLI | Search, inspect and sampling configuration commands | Add repeatable checks to runbooks |
| Collection | Automatic setup for qualifying new Next.js 16.5 projects | Review the default rule before traffic grows |
| Retention | 3 days on Hobby and 14 days on Pro and Enterprise | Match incident response to the available window |
Dashboard and CLI now use the same trace query
A dashboard query can run through `vercel traces search --query`. Teams can restrict it to one project, inspect a request ID and manage sampling rules from the CLI.
A runbook can now preserve the exact error query, time window and project filter. “Payment confirmations are late” should lead to the relevant route, API and database spans, not an unexplained waterfall.
New Next.js projects can start at 100 percent sampling
Starting with Next.js 16.5, a new Vercel project containing at least one Node.js function gets tracing after its first successful build. Vercel adds one sampling rule for 100 percent of requests in every environment and injects framework instrumentation at build time.
That suits a modest internal tool. A high-volume application should review data volume, sensitive attributes and environments before keeping the default. Removing all rules opts out.
Vercel's Tracing documentation says sampling applies to the entire trace, so a kept request retains all its spans and a dropped request keeps none. Preview and production traffic are both eligible when the configured rule matches.
Longer retention changes the incident window, not the evidence quality
Hobby retention rises from one hour to three days. Pro rises from one day to 14 days, and Enterprise rises from three days to 14 days.
A Monday incident found on Wednesday is more likely to retain evidence. It can still lack the custom span needed to explain the failure.
Add spans only for decisions worth observing, and never record secrets. A website maintenance agreement should name who investigates before retention expires.
Tracing still needs a deliberate sampling policy
Collecting every request is not automatically the right long-term policy. Low-volume systems may benefit from complete collection, while high-volume systems need rules that preserve useful failures without creating unnecessary data and cost.
OpenTelemetry's sampling guidance warns that poor sampling can miss critical information while sophisticated methods cost more to operate. Vercel uses the first matching project rule.
For a checkout, keep all error and high-latency paths if the rule system supports the required condition, then sample ordinary healthy traffic at a lower rate. Validate the rule with known test requests instead of assuming the configuration captures what its label implies.
A trace needs product context to support a decision
Infrastructure, fetch, framework and custom spans explain work and duration. They do not automatically prove that the user's task succeeded.
A search request may finish in 400 milliseconds and still return the wrong catalogue. Add a span or linked event for the retrieval stage, result count and fallback path, then compare the trace with a product outcome. The product analytics guide explains why behaviour and performance evidence should remain connected.
If the problem is browser experience rather than server work, pair traces with field performance data. The website performance optimization guide covers user-facing Core Web Vitals, which server traces do not replace.
Run one incident drill before broadening collection
Create one controlled slow dependency in a safe environment and find the request from dashboard and CLI. Record the query, owner, expected spans and action.
Then inspect what is missing. A serverless timeout may show the external call but not why the payload was unusually large. Add the smallest safe attribute or custom span that would change the diagnosis.
Teams already investigating worker memory can compare this workflow with Vercel Sandbox memory observability. The tools answer different questions, and neither replaces an owned incident process.
- Confirm which projects and environments are collecting traces.
- Review the default sampling rule and expected data volume.
- List attributes that must never contain secrets or personal data.
- Create one KQL query tied to a real product symptom.
- Verify the same search through the Vercel CLI.
- Check that framework, fetch and custom spans expose the needed path.
- Assign an incident owner before the retention window expires.
- Document the missing evidence and change the instrumentation deliberately.
What remains unknown after the GA announcement
General availability confirms support, not usefulness. Privacy and instrumentation quality still vary by product.
Vercel says beta pricing is unchanged, but publishes no universal cost per traced request. Measure usage before keeping 100 percent sampling.
Start with one incident drill. If a team member can move from a user symptom to the responsible span and action, the release has operational value.