Vercel Daemons can now export OpenTelemetry traces to Vercel Tracing

Daemons join Vercel Tracing

Vercel has extended its observability coverage to background work. According to the Vercel blog, Daemons, the platform's background worker offering, can now send OpenTelemetry traces to Vercel Tracing. Traces emitted by a daemon can be inspected alongside the rest of a project's traces, and Vercel frames the feature as useful for both engineers and the automated agents acting on their behalf.

A socket instead of an exporter endpoint

The mechanism is a platform-provided Unix socket. Vercel says each daemon receives its own socket for accepting OTLP/HTTP traces, and the path to that socket is exposed to the process through the VERCEL_OTEL_SOCKET_PATH environment variable. Because the SDK detects the socket on its own, a daemon does not need to be pointed at an external collector endpoint or supplied with credentials to ship telemetry.

For Node.js daemons the integration is close to zero-config. Upgrading the @vercel/otel SDK to version 2.3.0 or later enables automatic trace export under the default configuration, and the SDK then forwards the spans a worker records to Vercel. The one requirement Vercel highlights is that OpenTelemetry must be initialised before the worker starts, which amounts to a single call to the SDK's registerOTel function with a chosen service name, such as "my-daemon".

Querying spans from the CLI

Once exported, daemon spans become available through the Vercel CLI. A traces search command can filter by project and service name and return results as JSON, a format Vercel points to as convenient for agents. The example in the changelog, vercel traces search --project my-project --service my-daemon --json, fetches a daemon's spans from the last hour as structured output that either a person or an automated tool can parse. Vercel also directs readers to its daemon tracing documentation for further detail.

Why it matters

Background workers have traditionally been an observability blind spot. They operate outside the request/response cycle, so their latency spikes, retries and silent failures often fail to appear in the same place as web traffic, and teams frequently bolt on a separate collector or vendor just to see them. By funnelling daemon spans into Vercel Tracing through the same OpenTelemetry pipeline the platform already uses, Vercel collapses that gap: a single trace view can now cover both the frontend request that enqueued a job and the worker that processed it.

Two design choices stand out. First, using an automatically detected Unix socket removes the endpoint-and-credentials setup that usually accompanies OTLP export, lowering the friction of instrumenting workers at all. Second, making the CLI emit JSON suggests Vercel expects debugging workflows to become increasingly agent-driven: an agent that notices a problem could search a daemon's spans directly rather than waiting for a human to open a dashboard. For teams already running workloads on Vercel, the practical takeaway is simple: update @vercel/otel to 2.3.0 or later, keep the default configuration, initialise the SDK before the worker starts, and background workers stop being invisible.