Node.js Monitoring Dashboard: 8 Production Panels

A Node.js monitoring dashboard should tell you whether users are affected, which part of the runtime changed, and where to inspect next. A wall of CPU and memory charts cannot answer those questions alone. Start with eight panels in three rows: request impact, runtime health, and trace evidence.

This is a dashboard blueprint, not an importable Grafana template. You can build it with an OpenTelemetry and Grafana stack or a managed APM. The panel names and checks stay useful in either setup.

The eight panels

Keep the first three panels visible without scrolling. They show whether an incident affects requests. Place the runtime panels below them, then link each route view to example traces. This order prevents a memory spike from becoming the assumed cause of an unrelated slow request.

Use bounded dimensions such as service, environment, route template, method, and status class. Do not make a separate metric series for every user ID or raw URL. If you use Grafana, its dashboard variables can apply service and environment selections across panels.

Define each signal before drawing it

Request rate counts completed requests in a fixed window. Error rate needs the same request population in its numerator and denominator. Show both beside latency, because a low-traffic route can have a noisy percentile, and a failing route may appear fast when it returns errors early.

For response time, keep route p95 and p99 separate from a service-wide average. Compare a slow route with its own normal range. Then open traces from the same route and time window. A service average can hide one painful route.

Node.js provides two runtime measurements through node:perf_hooks: monitorEventLoopDelay() and performance.eventLoopUtilization(). Event loop delay values are nanoseconds, so divide by 1e6 before displaying milliseconds. Utilization is a fraction, so label its axis clearly if you display it as a percentage. The Node.js event loop guide explains how to interpret both signals.

For memory, show both heapUsed and resident set size. The Node.js process documentation explains that heapUsed measures V8 heap use, while rss includes the whole process. A growing RSS line with a steady heap line does not by itself prove a JavaScript heap leak.

Record runtime metrics in a Node.js service

Tracekit's current Node.js SDK guide documents counters, gauges, and histograms. The following example adds event loop delay, utilization, and memory to an already initialized Tracekit client. Keep the SDK initialization in the application's early startup path, as shown in the Node.js APM guide.

import { monitorEventLoopDelay, performance } from 'node:perf_hooks'
import { memoryUsage } from 'node:process'
import { client } from './instrumentation.js'

const delay = monitorEventLoopDelay({ resolution: 20 })
const delayP95 = client.gauge('nodejs.event_loop.delay_p95_ms')
const utilization = client.gauge('nodejs.event_loop.utilization_ratio')
const heapUsed = client.gauge('nodejs.memory.heap_used_bytes')
const rss = client.gauge('nodejs.memory.rss_bytes')

let previous = performance.eventLoopUtilization()
delay.enable()

setInterval(() => {
  const current = performance.eventLoopUtilization(previous)
  previous = performance.eventLoopUtilization()

  delayP95.set(Number(delay.percentile(95)) / 1e6)
  utilization.set(current.utilization)

  const memory = memoryUsage()
  heapUsed.set(memory.heapUsed)
  rss.set(memory.rss)
  delay.reset()
}, 60_000).unref()

This records one p95 delay value per interval. It does not export the full delay distribution. Keep that distinction clear when you label the panel. Measure request latency separately with request spans or a request-duration histogram. Do not treat event loop delay as request response time.

Tracekit's custom metrics guide explains how to view metrics in Metrics Explorer and add metric widgets to dashboards. Tracekit is not a general log-ingestion system. Keep normal application logs in your logger, and use traces to inspect individual requests.

Turn a red panel into a useful investigation

Use the panel combination, not one chart, to choose the next step:

A trace shows where time went, but a wide span does not prove which JavaScript function used CPU. Node.js CPU profiling is the next tool for that question. Tracekit does not collect continuous CPU profiles.

For a database pattern, inspect repeated child spans. The N+1 query guide gives a trace-based investigation method. For a route-specific latency drilldown, use the Node.js response time guide.

Grafana or a managed APM?

If your team already exports metrics to Prometheus, Grafana can show these panels. Add service, environment, and route variables, then link the dashboard to your trace backend. Grafana's dashboard documentation covers panels and links. You still need to define the metrics and verify that the selected trace matches the chart window.

If you use Tracekit, the Node.js integration sends traces and supports custom metrics. Its Metrics Explorer and dashboard widgets can show the runtime measurements above. Tracekit alert rules cover service error rate, latency, and throughput. Connect a dashboard change to a representative trace before you decide what code to change.

Check the dashboard with one controlled request

Before you trust the dashboard in an incident, send a request through a known route that calls a database or another service. Verify all of these items:

1. Request rate increases for the expected route and environment.
2. The request appears in the response-time distribution.
3. Its trace contains the server span and the expected dependency span.
4. Event loop and memory panels show the correct units.
5. The dashboard link opens a trace from the same time window.
6. A worker or queue job appears under its own service when it runs outside the request.

If one item fails, fix instrumentation before adding more panels. A small dashboard with a reliable trace path is more useful than a large dashboard with missing evidence.