Vercel Daemons Can Now Send Traces Directly to Vercel Tracing

What happened

On November 13, 2026, Vercel announced in its changelog that Vercel Daemons can now send OpenTelemetry traces to Vercel Tracing. In Vercel's words, this lets you and your agents inspect the operations of background workers next to the rest of the traces in your project. The post was written by Gal Schlezinger, a software engineer on Vercel's infrastructure team. It is marked as a one-minute read. It is short, but the details are concrete.

How it works

The announcement describes three steps. First, Vercel provides each daemon with a Unix socket that receives OTLP/HTTP traces, and it sets the path of that socket in the environment variable VERCEL_OTEL_SOCKET_PATH. Second, you upgrade @vercel/otel to version 2.3.0 or later. With that version, Node.js daemons that use the default configuration export traces automatically: the SDK detects the socket and sends the spans your worker records to Vercel. Third, you initialize OpenTelemetry before the worker starts. The official example is two lines in worker.ts. It imports registerOTel and calls registerOTel with a serviceName of 'my-daemon'. You choose the service name yourself.

How to read the data

The spans are available through the Vercel CLI. The command in the announcement is vercel traces search, with --project to name the project, --service to name the service, and --json to print JSON. Vercel says you can search by service name within a project and get JSON back for your agents. The caption of the example says it searches daemon spans from the last hour. The post closes with a link to the daemon tracing documentation. For anything beyond these lines, the documentation is the reference.

Why it matters

This section is our reading, not the text of the announcement. A background worker has no page request as a clear entry point. When it misbehaves, a developer often has only logs to read. A trace splits one operation into timed spans, so you can see which step used the time. The practical value of this change is that daemon spans appear in the same place as the other traces of the project. You do not build a separate collection path, and you do not choose where to send the data, because the platform gives the path through an environment variable and the SDK finds it. Receiving on a Unix socket also means the data moves inside the machine, so a daemon needs no separate outside collector address. The post does not go into this point, so we offer it only as a general remark.

A second point is that the feature is friendly to agents. The post says the CLI can return JSON for your agents. So asking a coding agent or an operations agent to query the daemon spans of the last hour is a use that Vercel itself has in mind. It fits a wider trend of platforms opening observability data to automated tools.

Limits to keep in mind

The announcement says only that Node.js daemons with the default configuration export traces automatically, and it asks for @vercel/otel 2.3.0 or later. It says nothing about other runtimes, custom configurations, sampling, retention or pricing, and we will not guess. Check the documentation when you need those answers. The post also does not say whether the feature is open to every plan, or whether the daemon itself has a version requirement. Confirm both before you rely on it. The example stresses that OpenTelemetry must start before the worker does. It is common sense that work done earlier than that may go unrecorded, but the post does not spell out the consequence.

Summary

This is a small and practical update. For a Node.js daemon with the default configuration and a platform-provided Unix socket, upgrade @vercel/otel to 2.3.0 or later, call registerOTel before the worker starts, and the daemon spans appear in Vercel Tracing, where vercel traces search can return them as JSON. For teams that already run background tasks on Vercel Daemons, the cost of change is low, and the feature is worth a trial.