Start with the storage. A module-scope `let` is one slot, allocated when the instance loads the module, and Next.js loads `instrumentation.ts` before any other application module [1]. `register()` fires at that same moment, once [2]. Every request that lands on the instance afterwards shares that one slot [7]. So you have one slot per instance and one required value per in-flight request, which means the assignment is only correct while exactly one request is running [1].
The runtime behaviour is ordinary. Request A writes its ID and awaits something. Request B writes over the slot. A resumes and reads B's value. The field notes describe this as shared mutable state across every request currently running on the instance, with interleaving requests stomping on each other's value [15].
Which is why the local result does not transfer. `next dev` rarely has more than one request in flight against the same process [9], so a green local run establishes one thing: concurrency was one. For the pass to mean anything in production you would need one request per instance there too, and reusing the instance is the point of the platform's design [7]. Development is a load test with a sample size of one.
The correct store is already in the process. OpenTelemetry's SDK carries request context in `AsyncLocalStorage`, and per the same notes that is the mechanism that actually keeps a value scoped to one request [10]. The cost is the one the author was avoiding when he reached for the global: the user ID has to be threaded through the call layers, five of them in his case, or pulled back out of that context at the point of use [16].
Adoption cost on the tracing side is genuinely low, and the packaging is good work. `registerOTel({ serviceName })` from `@vercel/otel` covers exporter selection, batch span processor configuration and resource attributes in one call [4]. By hand you are choosing a span processor, a context manager and an exporter, and getting the registration order right before any other module loads [5]. Point `OTEL_EXPORTER_OTLP_ENDPOINT` at a collector and Honeycomb, Axiom, Datadog or a self-hosted OpenTelemetry Collector will take the spans [11]; on Vercel, the platform's own Observability tab picks up the same data once `@vercel/otel` is registered, which covers a lot of debugging without a separate backend [12]. The full Node OpenTelemetry SDK needs the Node.js runtime, which Fluid Compute makes the practical default there anyway, and the older edge runtime was never a good host for a stateful SDK [13]. If your setup snippet came from a Next.js 13 or 14 tutorial, delete the `experimental.instrumentationHook` flag, because the behaviour has been stable since 15 [3].
One more thing worth budgeting for: a trace, a structured log and a metric each answer a different question about the same request, and exporting only one of them leaves the gaps the other two would have closed [14]. That is an argument for wiring all three, not for skipping the context work that makes any of them attributable.
My context is an app already on Vercel's Node runtime, where this is a correctness fix with a privacy blast radius rather than a performance knob. The slot arithmetic travels, though: the same failure shows up in any environment that reuses one process across concurrent requests [17].
