ServerDevTools vs Server-Timing
Compare response-header timing metrics with in-process request inspection.
Server-Timing and ServerDevTools can be used together, but they solve different parts of the debugging workflow. Server-Timing is an HTTP response header that an application or server-side tool supplies so supporting browser tools and APIs can expose selected server metrics. ServerDevTools is an in-process Node.js request inspector that captures the request details and supported child operations produced by the SDK’s instrumentations.
Minimal Server-Timing example
The application must calculate and send the metric itself:
Server-Timing: db;dur=12.4The browser can show this metric in supported developer tools, and same-origin web code can read server timing entries through the Performance API . This header does not by itself create a trace, discover child operations, or persist history.
Capability comparison
| Area | ServerDevTools | Server-Timing |
|---|---|---|
| Setup | Install the SDK, preload it before supported libraries, configure dashboard auth, and mount devtools.middleware. | Measure metrics in the application or server tooling and add a Server-Timing response header. |
| Timing visibility | Inspect request duration and supported child spans in the local dashboard, including linked database, Redis, and outbound HTTP operations when instrumentation and request context are present. | Expose application-provided metric names, durations, and descriptions to supporting browser tools/APIs for that response. |
| Linked operations | Correlates an incoming request with supported framework, database, Redis, and outbound HTTP spans. | Provides no automatic operation discovery or trace correlation; the application must define and emit each metric. |
| Request details | Can persist supported request/response metadata, selected headers and bodies, errors, and optional current-user data when capture conditions allow. | Carries timing metrics in a response header; it does not provide request bodies, database statements, or exception details by itself. |
| Persistence | Stores inspection history in local SQLite at ./server-devtools.db by default. | Has no persistence or history by itself; the client or another tool decides whether to retain the metric. |
| Debugging workflow | Open /_devtools, find a request, and inspect its execution tree and details. | Inspect the response in browser developer tools or read supported Performance API entries from the client side. |
When to use each
Use Server-Timing when a client-facing response needs a small set of server metrics, such as a database duration or cache lookup time. Choose the metrics and audience deliberately: timing headers can expose application or infrastructure details, especially on public responses. The Server-Timing specification defines the header format and processing model.
Use ServerDevTools when you need to investigate what happened inside a Node.js request: the request and response, supported database or Redis work, outbound calls, errors, and the timing relationship between those operations. Availability depends on preload order, active request context, framework support, parsers, and the instrumented driver.
For a practical workflow, emit a small Server-Timing metric for a browser-facing signal and use ServerDevTools privately to investigate the full supported request trace. They are complementary. ServerDevTools does not automatically add Server-Timing headers, and Server-Timing is not a competing SDK or a complete distributed-tracing system.
Deployment note
Both approaches require access decisions. Protect the embedded ServerDevTools dashboard and its captured data; it is served by the application and uses configured dashboard credentials. Restrict Server-Timing metrics to the responses and users that should see them, because response headers can reveal sensitive timing or infrastructure information.