After hours of calm operation, a Node.js application may abruptly begin using too much CPU power. The program may cease responding to queries within its typical response time, background jobs lag behind, and API answers become slower.

The problem is that excessive CPU utilization does not necessarily indicate that the program is processing too many requests. An inefficient loop, costly JSON processing, regular expression evaluation, excessive trash collection, or a dependency that handles CPU-intensive tasks can all cause an abrupt rise. JavaScript typically operates on a single main thread per process, but Node.js has an event-driven design. That thread can't react quickly to other callbacks and incoming requests when it spends too much time on CPU-intensive tasks. CPU bottlenecks are not always avoided by Node.js's support for worker threads and extra processes.

Measuring the issue, figuring out which process or execution route is to blame, reproducing the workload when feasible, and confirming the improvement following a modification are the best ways to look into a CPU spike.

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

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.