How to Find the Cause of Sudden CPU Spikes in a Node.js Application

A Node.js application can run smoothly for hours and then suddenly start consuming excessive CPU. API responses become slower, background jobs fall behind, and the application may stop responding to requests within its normal response time.

The challenge is that high CPU usage does not always mean the application is handling too many requests. A sudden spike can also result from an inefficient loop, expensive JSON processing, regular expression evaluation, excessive garbage collection, or a dependency that performs CPU-intensive work.

Node.js uses an event-driven architecture, and JavaScript generally runs on a single main thread within each process. When that thread spends too much time performing CPU-intensive work, it cannot respond promptly to other callbacks and incoming requests. Although Node.js supports worker threads and additional processes, those capabilities do not automatically prevent CPU bottlenecks.

The most effective way to investigate a CPU spike is to measure the problem, identify the process or execution path responsible, reproduce the workload when possible, and verify the improvement after making a change.

This article explains how to investigate sudden CPU spikes in Node.js applications using operating system metrics, event loop monitoring, profiling, and practical debugging techniques.

Understand Why Node.js CPU Usage Increases

Before collecting diagnostic information, understand the difference between application workload and inefficient processing.

A CPU spike may occur when an application receives a sudden increase in traffic. In this situation, the CPU may be performing useful work, but the application may need more capacity to handle the demand.

In other cases, CPU consumption increases even though traffic remains relatively stable. This can indicate an inefficient code path, a change in input data, an unexpected loop, or a background task that consumes more processing time than expected.

Common causes include:

Large JSON serialization or deserialization operations.
Synchronous file system operations on the main thread.
Expensive loops or repeated calculations.
Regular expressions that require excessive backtracking.
Large array transformations or sorting operations.
Frequent garbage collection caused by memory allocation pressure.
Cryptographic operations, compression, or image processing.
A sudden increase in background job activity.
A dependency that performs unexpected CPU-intensive work.

A database problem can also increase application CPU usage indirectly. For example, an application might repeatedly process large result sets because a query returns more records than expected.

The first task is to determine whether the CPU increase comes from legitimate workload growth or unnecessary processing.

Confirm the CPU Spike at the Process Level

Start by checking whether the CPU spike affects the entire server or a particular Node.js process.

On a Linux server, use:

top

For a more detailed view of individual processes, use:

pidstat -u -p ALL 1

The pidstat command is provided by the sysstat package on many Linux distributions. It reports process-level CPU usage at regular intervals.

These tools help answer several questions:

Is the Node.js process responsible for most of the CPU usage?
Are multiple application processes consuming CPU simultaneously?
Is the spike limited to one process?
Does the increase occur continuously or only for short periods?

If the application runs in a container, also check container CPU usage and CPU throttling metrics. A container can experience CPU throttling when it reaches its configured CPU limit, even when the underlying host has additional capacity.

On managed platforms, use the provider's process, container, or application monitoring tools when operating system access is unavailable.

Inspect the Node.js Process

You can start a Node.js application with a process identifier visible through the operating system:

node server.js

Then inspect the process using the available monitoring tools.

If several Node.js workers or application instances are running, identify which process is consuming CPU rather than assuming every instance is affected.

A single overloaded worker may explain why some requests become slow while others remain responsive.

Measure Event Loop Delay

Node.js relies heavily on its event loop to process callbacks, timers, and asynchronous operations.

When JavaScript performs a long-running synchronous operation, the event loop cannot process other scheduled work until that operation finishes. This can increase request latency even when the application continues running.

Node.js provides the built-in perf_hooks module, which includes monitorEventLoopDelay() for measuring event loop delay.

The following example records event loop delay periodically:

const {
    monitorEventLoopDelay
} = require('node:perf_hooks');

const histogram = monitorEventLoopDelay({
    resolution: 20
});

histogram.enable();

setInterval(() => {
    console.log({
        eventLoopDelayMeanMs:
            histogram.mean / 1e6,
        eventLoopDelayP95Ms:
            histogram.percentile(95) / 1e6,
        eventLoopDelayMaxMs:
            histogram.max / 1e6
    });

    histogram.reset();
}, 10000);

The monitor measures delays in nanoseconds, so dividing the values by one million converts them to milliseconds.

This example reports the mean, 95th percentile, and maximum event loop delay over each reporting interval.

The results can help reveal whether the application is struggling to process scheduled work promptly.

However, event loop delay is not a direct CPU measurement. High delay may result from synchronous JavaScript execution, operating system scheduling, CPU throttling, or other conditions. Low event loop delay also does not rule out CPU-intensive work running in worker threads or other processes.

In production, export these measurements to your monitoring system instead of relying only on console output. Excessive logging can create additional overhead and make an incident harder to investigate.

Monitor Event Loop Utilization

Event loop delay measures scheduling delays, while event loop utilization provides information about how busy the event loop is relative to its idle time.

Node.js exposes this measurement through performance.eventLoopUtilization().

const {
    performance
} = require('node:perf_hooks');

let previousUtilization =
    performance.eventLoopUtilization();

setInterval(() => {
    const currentUtilization =
        performance.eventLoopUtilization(
            previousUtilization
        );

    previousUtilization =
        performance.eventLoopUtilization();

    console.log({
        eventLoopUtilization:
            currentUtilization.utilization
    });
}, 10000);

The utilization value ranges from zero to one. A value closer to one indicates that the event loop spent a larger proportion of the measured interval in an active state.

Interpret this metric alongside CPU usage, request volume, and event loop delay. High utilization can indicate that the main event loop is busy, but it does not identify the specific function responsible.

Also note that event loop utilization is not equivalent to total process CPU utilization. Work performed in worker threads and other processes requires separate observation.

Use the Node.js CPU Profiler

Once you confirm that a Node.js process is responsible for the spike, the next step is to identify the functions consuming the most processing time.

A CPU profile records execution samples and helps show where the JavaScript runtime spends its time.

Node.js supports CPU profiling through the built-in V8 profiler.

For example, start the application with CPU profiling enabled:

node --cpu-prof server.js

The runtime records a CPU profile that can be opened in a compatible profiling tool, such as the Performance panel in Chrome DevTools.

The exact profile output location and filename depend on the Node.js version and runtime options.

A CPU profile can help identify:

Functions that account for a large proportion of sampled execution time.
Repeated calls to the same expensive function.
Costly array transformations or sorting operations.
JSON processing that dominates application work.
Functions from third-party dependencies that consume substantial CPU.
Unexpected call paths that become expensive under production-like workloads.

Interpret the Profile Correctly

Suppose a profile shows that a function responsible for formatting a large response consumes a substantial share of the sampled CPU time.

This finding gives you a concrete investigation target. You can examine the function's input size, call frequency, algorithmic complexity, and opportunities to reduce repeated processing.

However, a high percentage of profile samples does not automatically mean the function contains a bug. It may be doing the main work the application was designed to perform.

Compare the profile with the application's expected workload and performance requirements before changing the implementation.

For production incidents, use a controlled profiling window and evaluate the overhead of the selected profiling method. Avoid generating large diagnostic files continuously without a clear retention and storage strategy.

Find Expensive JavaScript Operations

Several JavaScript patterns can increase CPU consumption unexpectedly.

Large Array Processing

Consider an endpoint that filters and sorts a large collection on every request:

function getRecentOrders(orders, customerId) {
    return orders
        .filter(order =>
            order.customerId === customerId
        )
        .sort((a, b) =>
            b.createdAt - a.createdAt
        )
        .slice(0, 50);
}

This function filters the entire array and sorts the matching records before returning the first 50 entries.

If the array contains a large number of orders and the function runs frequently, it may perform considerable work.

Possible improvements depend on the application:

Retrieve only the required records from the database.
Avoid repeatedly loading and sorting the same data.
Use an appropriate indexed data-access pattern.
Reduce unnecessary copies or transformations.
Consider a more efficient selection algorithm when only a small number of top results is required.

Do not assume that moving the same operation into another JavaScript function will make it faster. The goal is to reduce the amount of work performed or choose a more suitable algorithm.

Synchronous Operations

Synchronous operations block the JavaScript thread while they complete.

For example:

const fs = require('node:fs');

function loadConfiguration() {
    return fs.readFileSync(
        './config.json',
        'utf8'
    );
}

This code reads the file synchronously. While the read is in progress, the current JavaScript thread cannot process other callbacks.

For startup configuration, this may be acceptable because the application is not yet serving requests. Repeated synchronous file access inside a request handler is more likely to create a problem.

An asynchronous alternative is:

const fs = require('node:fs/promises');

async function loadConfiguration() {
    return fs.readFile(
        './config.json',
        'utf8'
    );
}

The asynchronous version avoids blocking the JavaScript thread while waiting for the file operation to complete.

However, asynchronous APIs do not guarantee that all work is performed without CPU cost. Parsing a large JSON document, for example, still requires processing. The benefit depends on which part of the operation is blocking.

Expensive Regular Expressions

Certain regular expressions can take an unexpectedly long time to process specific inputs. Patterns with problematic backtracking behavior may become especially expensive when presented with long or adversarial strings.

If a CPU profile points to regular expression processing, examine the pattern and input size.

Consider simplifying the expression, using a more predictable matching strategy, or limiting input length where appropriate. Test worst-case inputs rather than validating only ordinary examples.

Check Whether Garbage Collection Is Contributing

Node.js uses the V8 garbage collector to reclaim memory that is no longer needed.

Applications that allocate large numbers of short-lived objects may trigger frequent garbage collection. During collection, the runtime must perform additional work to manage memory, which can affect CPU consumption and response latency.

Look for related symptoms:

Memory usage increases rapidly during the spike.
Heap usage repeatedly rises and falls.
Request latency increases around garbage collection activity.
CPU profiles show substantial runtime or garbage collection activity.

You can collect additional runtime diagnostics using Node.js options, such as:

node --trace-gc server.js

This option emits garbage collection diagnostic information. Output format and details vary by Node.js version.

Use such tracing carefully in production because it can generate significant log volume. A safer starting point is to use runtime metrics and profiling in a representative test environment.

If garbage collection is contributing to the spike, investigate allocation patterns and object lifetimes. Repeatedly creating large temporary arrays or duplicating large objects may be more effective to fix than attempting to change the garbage collector's behavior.

Increasing the heap limit alone does not eliminate unnecessary allocations. It can also allow memory consumption to grow further before collection occurs.

Investigate CPU Spikes in Background Tasks

Not all CPU-intensive work originates from HTTP requests.

Scheduled jobs, message consumers, report generation, data transformations, and batch processing can compete with request handling for CPU resources.

For example, an application might start processing every queued message concurrently without limiting the number of active jobs. A large backlog can then cause many CPU-intensive tasks to run at once.

Investigate background work by monitoring:

Number of jobs running concurrently.
Queue depth and processing rate.
CPU usage by worker process.
Job duration and input size.
Request latency while background processing is active.

If background work is the cause, consider limiting concurrency, splitting large tasks into smaller units, or running CPU-intensive workloads in separate worker processes.

Node.js worker threads can be useful for CPU-intensive JavaScript tasks because they allow work to run on separate threads. However, they still consume CPU resources and should be sized according to the available capacity.

For larger deployments, separate worker processes or dedicated worker services may provide better isolation between background workloads and latency-sensitive API requests.

Common Symptoms and Troubleshooting Steps

Symptom	Possible cause	What to investigate
CPU increases while traffic remains stable	An inefficient code path or background task	Compare CPU profiles before and during the spike
CPU and request volume increase together	Legitimate workload growth or insufficient capacity	Review request rates, throughput, and CPU per request
CPU is high and event loop delay increases	Main-thread work is taking too long	Inspect synchronous operations and CPU profiles
CPU rises alongside frequent garbage collection	Excessive object allocation or memory pressure	Review heap metrics, allocation patterns, and GC diagnostics
Only one application process uses high CPU	A hot worker or uneven workload distribution	Profile that process and examine its assigned work
Container CPU usage reaches its limit	CPU throttling	Check container limits and throttling metrics
API latency increases but Node.js CPU stays low	Database, network, lock, or other waiting bottlenecks	Inspect traces, downstream latency, and wait time
Background jobs slow down API requests	Shared CPU capacity or excessive worker concurrency	Measure job concurrency and isolate worker workloads

Best Practices for Preventing Future CPU Spikes

A practical monitoring strategy should help the team detect a problem before it becomes a prolonged incident.

Establish a baseline. Record normal CPU utilization, request volume, response latency, event loop delay, and memory usage.
Monitor both averages and percentiles. Average latency can hide short but severe periods of degradation.
Use profiling to identify expensive functions. Avoid making optimization decisions based only on assumptions or isolated code snippets.
Track background workloads separately. Monitor queue depth, job duration, and worker concurrency.
Test with realistic input sizes. Code that performs well on a small development dataset may become expensive with production-scale data.
Review dependency changes. A new library version or configuration change can introduce additional processing.
Keep diagnostic overhead under control. Use focused profiling windows and avoid unnecessary high-volume logging.
Validate each optimization. Compare CPU usage, throughput, latency, and error rates under similar workloads before and after the change.

Advantages and Limitations of CPU Profiling

CPU profiling provides evidence about where a Node.js process spends its execution time. It helps developers distinguish expensive application functions from assumptions about database, network, or framework overhead.

Combined with event loop metrics, process-level monitoring, and application traces, profiling can make CPU incidents easier to investigate and reproduce.

However, CPU profiles have limitations. Sampling profiles provide statistical evidence rather than a complete record of every instruction. A short-lived spike may finish before profiling begins, and a profile of one process may not explain work performed by other processes or services.

Profiling can also introduce overhead, depending on the collection method and workload. Results should therefore be interpreted alongside system metrics and the conditions under which the profile was collected.

Summary

Sudden CPU spikes in Node.js applications can result from increased traffic, inefficient JavaScript, synchronous operations, expensive regular expressions, garbage collection, or CPU-intensive background jobs.

Start by confirming which process is consuming CPU. Then inspect event loop delay and utilization, capture a CPU profile, and correlate the findings with request traffic, memory usage, container limits, and background activity.

Once the expensive operation is identified, reduce unnecessary work, improve the algorithm, limit concurrency where appropriate, or move CPU-intensive processing to dedicated workers.

The objective is not simply to reduce CPU utilization. It is to ensure that the application performs its required work efficiently while maintaining predictable response times and stable throughput under production workloads.