Observability: Server-side instrumentation

[chargome]

Hey there!

I'd like to open the discussion on instrumenting the React Router server runtime for emitting telemetry signals.

Current Problem

At Sentry, we've been running into difficulties instrumenting React Router Framework on the server-side since the switch from Remix. The problem boils down to this:

• With react-router v7 the server-runtime package has been moved to the core react-router package which is where our instrumentation needs to take place now.
• We cannot patch the createRequestHandler function anymore, details on this can be found in this issue.

Background on ESM instrumentation

Further, since React Router is emitting ESM (like many other frameworks), we and potentially other OpenTelementry SDKs rely on Node's register hooks for instrumenting server code. Unfortunately this comes with the downside that some deployment providers do not expose these options (e.g. Vercel or Netlify). In case anyone is interested this is well documented in this observability guide.

Two Potential Solutions for a more stable way forward

React Router OTEL support

• The framework could expose an instrumentation entrypoint for the server. This could likely be a standardized instrumentation.ts file which is guaranteed to run before any server code. An example for this approach would be Next.js.
• Building on top of this, the framework could natively support emitting OTEL spans from within the framework itself for crucial observability signals e.g. within createRequestHandler. This way 3rd parties could simply pick up these spans without having to patch any internals.

Diagnostics Channel

Leveraging the native Node diagnostics channel functionality, React Router could emit signals via this channel for requests, server-loaders, server-actions, etc. – which could then be picked up by third party observability providers. This feature is also runtime agnostic (e.g. Node, Bun, Deno, Cloudflare). We could even build and maintain an official OpenTelemetry instrumentation around this approach.

A good example for this approach would be fastify.

Impact

The React Router community would benefit from having more structured guidance on observability, as current resources on best practices in this area are still quite limited.

I would appreciate any thoughts on this topic and would also offer help contributing this feature to the framework once we identify a clear way forward!