# Monitoring and Alerting with Node.js: A Practical Setup

> Set up Node.js monitoring and alerting around errors, slow requests, traffic, and event loop health without creating noisy pages.

- Published: 2026-10-26T00:00:00.000Z
- Updated: 2026-10-26T00:00:00.000Z
- Author: Terry Osayawe
- Tags: nodejs, alerting, performance-monitoring
- Canonical: https://tracekit.dev/blog/monitoring-and-alerting-with-nodejs

**Monitoring and alerting with Node.js** works best when each alert names a user problem and a next action. Start with failed requests, slow requests, and missing traffic. Use event loop and memory measurements to explain the problem, not to page for every short spike.

This guide gives you a small alert plan. It also shows how to test each rule before you trust it in production.

## Start with three service alerts

Start with a rule for each important service. Measure a normal traffic period first. A threshold copied from another application can miss a real failure or create noise.

| Signal | Page when | First check |
| --- | --- | --- |
| Error rate | Failures stay above your service baseline and affect users | Open failed request traces and compare the latest release |
| P95 request latency | A critical service stays slower than its user target | Open slow traces and find the longest child span |
| Throughput | A service that normally receives traffic becomes unusually quiet | Check an independent health probe and telemetry delivery |

Tracekit [alert rules](/docs/alerts) support service error rate, latency, throughput, and health score from trace data. The latency rule can use average, P50, P95, or P99. Start with P95 for a service that users depend on. A low-throughput rule needs a known traffic pattern. It is a poor choice for a service that is naturally idle at night.

Keep an independent external probe for a complete outage. A trace-based alert and its data pipeline can fail together. The [Prometheus alerting guidance](https://prometheus.io/docs/practices/alerting/) recommends alerts for user symptoms and separate checks for monitoring health.

## Add Node.js runtime measurements for diagnosis

Request alerts tell you *that* users have a problem. Runtime measurements help you find *why*. Track these values on the same dashboard as request impact:

- Event loop delay: Does the loop wait longer than normal before it runs scheduled work?
- Event loop utilization: Is the loop busy during the slow period?
- Heap used and resident memory: Does memory grow after traffic returns to normal?
- Queue depth: Does background work arrive faster than workers finish it?

Node.js provides [`monitorEventLoopDelay()` and `eventLoopUtilization()`](https://nodejs.org/api/perf_hooks.html). It provides [`process.memoryUsage()`](https://nodejs.org/api/process.html#processmemoryusage) for memory measurements. The [event loop measurement guide](/blog/nodejs-monitoreventloopdelay-eventlooputilization) shows how to sample these values and interpret them together.

Tracekit's [Node.js SDK](/docs/languages/nodejs#custom-metrics) can emit counters, gauges, and histograms. Its [Metrics Explorer](/docs/metrics) can chart custom runtime measurements. The current Tracekit alert rules use trace data for service alerts. Do not assume a custom event loop metric can drive those rules. Use another alert system if you need a page from that custom metric.

## Decide which signal deserves a page

Use a page for a condition that needs prompt human action. Send a ticket or dashboard note for a slow trend with no current user impact. For example, rising heap use can prompt investigation. A short event loop delay spike alone usually cannot tell you whether users suffered.

Ask four questions before you create a rule:

1. Which user action fails or slows down?
2. How many requests occur in the rule's time window?
3. Who receives the alert, and what can that person do?
4. Which trace, dashboard, and release view will the message link to?

The [Google SRE alerting workbook](https://sre.google/workbook/alerting-on-slos/) explains why low-traffic services need special care. One failure can make their error rate look severe. Start with a window that has enough requests to support your decision. If you use an error budget, review several windows before you copy a burn-rate example into your own system.

## Test the full alert path

A rule that looks correct in a form can still fail when an incident starts. Test with safe, controlled traffic:

1. Send successful requests through a critical route. Confirm the service and route appear in traces.
2. Trigger a controlled error. Confirm its trace has the expected error status.
3. Create a slow test request. Confirm P95 changes in the expected service window.
4. Check that the rule sends one useful notification to the intended channel.
5. Open the linked trace and identify the slow span or failure.
6. Stop the test. Confirm the alert clears or its cooldown behaves as expected.

Do not test a low-throughput rule by stopping your only production service. Use a test service or a safe maintenance window. Keep the external health probe active during the test.

If a notification lacks a trace link, service name, or clear owner, improve that path before adding more rules. The [Node.js monitoring dashboard blueprint](/blog/nodejs-monitoring-dashboard-production) shows one way to place request impact, runtime health, and trace evidence together.

## Investigate an alert in a fixed order

First, confirm that users are affected. Compare the alert window with traffic, errors, and route latency. Then open one representative slow or failed trace. Check its child spans before blaming the Node.js runtime.

If the trace points to a database, inspect query count and duration. If the trace has no slow child span, compare event loop delay, utilization, and memory. Check whether the problem started with a release. For a narrow code path, Tracekit [dynamic logs](/docs/code-monitoring) can capture runtime state at a bounded capture point without a redeploy. Dynamic logs are not general log ingestion.

The [Node.js APM guide](/blog/node-js-monitoring-complete-guide-for-production-apps) covers instrumentation and missing trace checks. The [Node.js response time guide](/blog/nodejs-response-time-monitoring) covers route-level latency investigation.

## A small starting policy

For one user-facing Node.js service, start with an error-rate rule and a P95 latency rule. Add a low-throughput rule only when that service has predictable traffic. Put event loop delay, utilization, and memory beside these signals for diagnosis. Add an independent probe for complete outages.

Write the owner and first action beside each rule. Review a week of alerts. Remove rules that wake someone without a useful action. Adjust thresholds from your own request volume and user targets.