Node.js Performance: Event Loop, Clustering & Memory Leak Detection in 2026

Node.js performance is the backbone of scalable backend services in 2026. Whether you’re running a high-throughput API gateway, a real-time websocket server, or a data-intensive microservice, understanding what happens under the hood — the event loop, V8’s memory model, and how Node.js distributes load — separates resilient systems from fragile ones.

This guide covers every major dimension of Node.js performance optimization: how the event loop actually works (including libuv internals), what blocks it and how to detect it, how clustering multiplies throughput, how to find and fix memory leaks, and how to tune garbage collection. Real data, sourced benchmarks, and practical code examples throughout.

---

How the Node.js Event Loop Works

The event loop is the heart of Node.js’s non-blocking, asynchronous architecture. Understanding it is prerequisite to optimizing any production Node.js service.

libuv and the V8 Engine

Node.js sits on top of two critical layers: V8 (Google’s JavaScript engine, which compiles and executes your JS) and libuv (a C library that provides the event loop and async I/O operations). V8 handles JavaScript execution; libuv handles OS-level operations like networking, file I/O, and timers, exposing them to JavaScript through a unified event-driven interface.

When you call setTimeout, fs.readFile, or http.request, Node.js doesn’t spin a new thread for each operation. Instead, it offloads the work to libuv, which manages a thread pool (default size: 4, configurable via UV_THREADPOOL_SIZE) for I/O tasks, and uses OS-level async I/O mechanisms (epoll on Linux, kqueue on macOS) for networking.

The Six Phases

The Node.js event loop cycles through six distinct phases, each with its own queue of callbacks. Knowing which phase a given operation runs in tells you exactly how it interacts with — and potentially blocks — the loop.

1. Timers — Executes callbacks scheduled by setTimeout() and setInterval(). All timers are checked by comparing their expiration time against the current time, not against when they were queued.

2. Pending Callbacks — Executes I/O callbacks deferred from the previous cycle. Some errors (e.g., from TCP socket handling) are reported here.

3. Idle, Prepare — Used internally by libuv for its own bookkeeping. Not directly relevant to application code.

4. Poll — Retrieves new I/O events. If the poll queue is empty, Node.js will either wait for incoming I/O or skip to the Check phase. This is where most fs.readFile, http requests, and database queries execute.

5. Check — Executes setImmediate() callbacks immediately after the Poll phase. setImmediate() callbacks always fire before the next event loop iteration’s Timers phase.

6. Close Callbacks — Executes callbacks for events like socket.on('close', ...). Runs last in each iteration.

┌──────────────────────────────┐
│           timers             │  setTimeout / setInterval
├──────────────────────────────┤
│    pending callbacks         │  deferred I/O errors
├──────────────────────────────┤
│       idle, prepare          │  internal libuv
├──────────────────────────────┤
│           poll               │  I/O callbacks, fs, net
├──────────────────────────────┤
│           check              │  setImmediate()
├──────────────────────────────┤
│       close callbacks        │  socket.on('close')
└──────────────────────────────┘

The process.nextTick() queue is not part of the standard event loop phases — it runs after the current operation completes, before the next phase or the next iteration. This makes it the most immediate way to defer work within the current stack, but overuse can starve the event loop.

Event Loop Utilization (ELU)

Node.js v15+ exposes Event Loop Utilization (ELU) via the performance module in perf_hooks. ELU measures the percentage of time the event loop spent executing JavaScript (outside the event provider) versus idle. Unlike CPU utilization, ELU isolates event loop activity from CPU work.

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

const h = monitorEventLoopDelay({ resolution: 20 });
h.enable();

// Later, check utilization
setInterval(() => {
  const elu = process.eventLoopUtilization();
  console.log(`ELU: ${(elu.utilization * 100).toFixed(2)}%`);
}, 1000);

An ELU consistently above 80–90% indicates the event loop is saturated — new events will queue, and latency will spike.

---

Blocking the Event Loop

Node.js’s single-threaded model is both its strength and its Achilles heel. Every CPU-intensive synchronous operation that runs on the main thread blocks the event loop, stalling all other pending callbacks.

CPU-Bound Tasks

Any synchronous computation that runs long enough will freeze the event loop. Common culprits include:

• JSON serialization/deserialization of large payloads — JSON.stringify() and JSON.parse() are synchronous and block the entire loop
• Cryptographic operations — hashing, encryption/decryption without crypto.scrypt() async variants
• Image processing — resizing, transcoding, thumbnail generation
• Heavy regex on large strings — catastrophic backtracking patterns
• Data sorting and algorithmic complexity — O(n²) operations on large arrays

// BLOCKING: Do not use on large data in production
const result = JSON.parse(largePayload); // blocks for potentially seconds
crypto.createHash('sha256').update(largeFile).digest('hex'); // synchronous hash

// NON-BLOCKING alternatives
const result = await JSON.parse(largePayload); // still blocks V8, but yields
import('crypto').then(({ createHash }) => {
  createHash('sha256').update(largeFile).digest('hex'); // still sync
});
// Best: offload to a Worker thread
const { Worker } = require('worker_threads');

A 2025 RisingStack survey found that reducing synchronous CPU work by just 10% accelerated request processing by nearly 15% on average across surveyed production services. That’s a large return on a modest architectural change — a testament to how catastrophically synchronous blocking degrades Node.js throughput.

Synchronous Operations to Watch

Beyond explicit CPU work, these patterns are notorious event loop blockers:

Operation	Why It Blocks	Alternative
JSON.stringify on large objects	Synchronous memory allocation + traversal	Stream with JSONStream
for / forEach on large arrays	Synchronous iteration, no yield points	for...of with async iterators, split into chunks
require() on heavy modules at runtime	Synchronous file I/O + module compilation	Dynamic import()
Large Buffer operations	Synchronous memory operations	Streams, pipeline()
dns.lookup()	Calls OS resolver synchronously	dns.resolve()

Detecting Event Loop Blockers

The first step is measurement. You cannot fix what you cannot see.

1. async_hooks + custom timing:

const async_hooks = require('async_hooks');
const { triggerAsyncId } = async_hooks.createHook({ init() {} });

let lastCheck = Date.now();
setInterval(() => {
  const lag = Date.now() - lastCheck;
  if (lag > 100) {
    console.warn(`Event loop lag detected: ${lag}ms`);
  }
  lastCheck = Date.now();
}, 50);

2. Clinic.js Doctor — wraps async_hooks and perf_hooks to identify blocking operations:

npm install -g clinic
clinic doctor -- node server.js
# Then run your load test and press Ctrl+C to analyze

3. --trace-gc flag — traces garbage collection events to separate GC pauses from pure event loop blocking:

node --trace-gc --tracegc-verbose server.js

---

Event Loop Lag & Detection

Event loop lag is the time elapsed between when an event is supposed to fire and when it actually fires. In a healthy Node.js process, lag is sub-millisecond. As blocking operations accumulate, lag grows.

According to 2025 RisingStack research, healthy event loops typically stay under 5ms of lag. Lag jumps beyond 50ms during garbage collection pauses or CPU saturation events are common even in well-tuned systems. Sustained lag above 100ms is a production incident waiting to happen.

Measuring Event Loop Lag

Node.js built-in method:

const { performance } = require('perf_hooks');
const { eventLoopUtilization } = require('perf_hooks');

setInterval(() => {
  const elu = eventLoopUtilization();
  console.log({
    utilization: elu.utilization,
    active: elu.active,
    idle: elu.idle
  });
}, 1000);

PM2 / Keymetrics:

PM2’s built-in event loop lag metric is among the most actionable APM signals for Node.js services. It samples how long the event loop has been inactive and reports p50/p95/p99 lag values.

What Lag Tells You

• Lag < 5ms — Normal, healthy operation
• Lag 5–50ms — Elevated, typically GC-related. Investigate allocation patterns
• Lag 50–100ms — Significant blocking. Likely CPU-bound synchronous work or memory pressure
• Lag > 100ms — Critical. Immediate investigation required; users will experience timeouts

A 2026 Medium analysis on Node.js performance tuning noted that event loop lag is the earliest predictor of service outages — p95 latency explodes only after lag has been elevated for minutes, making it a critical leading indicator that most teams overlook until it’s too late.

Reducing Lag

1. Profile first — use Clinic.js to identify the top blocking operations
2. Offload CPU work to Worker threads or a separate process
3. Stream large data instead of buffering entirely in memory
4. Batch I/O operations to amortize the cost of each event loop tick
5. Tune GC (covered below) to reduce GC-related lag spikes

---

Node.js Clustering

Node.js’s single-threaded model means a single process can only utilize one CPU core. For CPU-bound or high-concurrency workloads, this is a hard ceiling. Node.js clustering solves this by spawning multiple worker processes that share the same server port, distributing load across all available cores.

child_process.fork

The most basic form of parallelism in Node.js is child_process.fork(), which spawns a new V8 instance:

const { fork } = require('child_process');

// Spawn a worker process
const worker = fork('./worker.js');

// Send messages between master and worker
masterProcess.on('message', (msg) => {
  console.log('Received from worker:', msg);
});

worker.send({ task: 'process-data', payload: largeDataset });

Each fork() creates an independent Node.js process with its own V8 instance, event loop, and memory space. Communication happens via IPC (Inter-Process Communication) through process.send() and process.on('message', ...). This is the raw primitive underlying the cluster module.

Benchmark context: A fork-based worker processing a 10MB JSON payload adds ~15–30ms overhead per fork operation but achieves true parallelism across cores. For sustained CPU-bound work, this is a net win starting around the second or third iteration.

The Cluster Module

The cluster module wraps child_process.fork() with built-in load balancing, shared port handling, and worker lifecycle management:

const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;

if (cluster.isPrimary) {
  // Spawn workers — one per CPU core
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`Worker ${worker.process.pid} died. Restarting...`);
    cluster.fork();
  });
} else {
  // Worker processes share the HTTP server
  http.createServer((req, res) => {
    res.end(`Handled by worker ${process.pid}`);
  }).listen(3000);
}

Each worker is a separate process, so a crash in one worker doesn’t bring down the entire server. The primary process acts as a load balancer, distributing incoming connections across workers using a round-robin strategy by default on Linux/macOS.

Sticky Sessions

By default, the cluster module distributes connections without regard to which worker is handling a given client’s session. For stateful services that store session data in memory on individual workers, this causes sessions to break when a client is routed to different workers across requests.

Sticky sessions solve this by ensuring a given client is consistently routed to the same worker. The most common approach is cookie-based affinity — the primary process inspects a session cookie and routes the connection to the worker that owns that session:

const cluster = require('cluster');
const http = require('http');

const workers = {};

if (cluster.isPrimary) {
  const availableCPUs = require('os').cpus().length;
  for (let i = 0; i < availableCPUs; i++) {
    const worker = cluster.fork();
    workers[worker.id] = worker;
  }

  // Route based on session cookie
  http.createServer((req, res) => {
    const workerId = getWorkerForSession(req.headers.cookie);
    const targetWorker = workers[workerId];
    
    if (targetWorker) {
      // Forward to the correct worker
      const message = { req, res };
      targetWorker.send(message);
    }
  }).listen(3000);
}

In production, NGINX or HAProxy can handle sticky session routing at the load balancer level, keeping your Node.js cluster logic simpler.

Load Balancing Strategies

The cluster module’s default round-robin load balancer works well on Linux and macOS. On Windows and some older Node.js versions, the OS-level SO_REUSEPORT mechanism is used instead. However, for high-performance production deployments, consider these alternatives:

Strategy	How It Works	Best For
Round-robin (default)	Connections distributed equally	Stateless services
Least connections	Route to worker with fewest active connections	Long-lived connections (WebSockets)
IP hash	Hash client IP to determine worker	Session-based services without cookies
Cookie-based affinity	Read session cookie to route	Stateful session data in workers

PM2 (pm2 start app.js -i max) automates clustering with zero code changes, adds built-in load balancing, and provides process management with automatic restarts. It’s the recommended approach for production deployments that need minimal operational overhead.

Clustering Speedup Benchmarks

Real-world clustering benchmarks consistently show near-linear throughput scaling up to the number of available cores, with diminishing returns as connection overhead grows:

• A Medium analysis on clustering benchmarks found that on an 8-core machine, a properly clustered Node.js HTTP server achieved ~6.5x throughput compared to a single process, with the gap widening under concurrent load.
• CPU-bound tasks (like cryptographic hashing or image processing) see the best scaling because there is no I/O wait to hide — each additional worker directly adds compute capacity.
• I/O-bound tasks (typical REST APIs) see 2–4x improvement on multi-core, limited by shared resources like database connections.

Key insight: More workers is not always better. Benchmark your specific workload — spawning more workers than CPU cores causes context-switching overhead that can actually reduce throughput.

---

Memory Leak Detection

Memory leaks in Node.js accumulate over time as objects are allocated but not freed by the garbage collector. Left unchecked, they cause heap growth, increased GC pause frequency, service degradation, and eventually OOM (Out of Memory) crashes.

—inspect and Chrome DevTools

The simplest way to start debugging memory issues is the built-in Node.js inspector:

node --inspect server.js

Then open chrome://inspect in Chrome, connect to your Node.js process, and use the Memory tab to take heap snapshots. The DevTools interface lets you:

1. Compare two snapshots to see which objects were allocated and not freed
2. Use the Retainer Tree to trace the reference chain keeping objects alive
3. Execute memory recordings (Allocation Timeline) to watch allocation patterns over time

// Programmatically trigger a heap snapshot
const v8 = require('v8');
const path = require('path');

function takeHeapSnapshot() {
  const filename = path.join(__dirname, `heap-${Date.now()}.heapsnapshot`);
  const filepath = v8.writeHeapSnapshot(filename);
  console.log(`Heap snapshot written to: ${filepath}`);
  return filepath;
}

// Expose as an endpoint (protect in production!)
app.get('/debug/heap-snapshot', (req, res) => {
  const file = takeHeapSnapshot();
  res.json({ file });
});

Heap snapshots can be 1–10x the heap size on large processes; ensure adequate disk space before taking snapshots in production.

Heap Snapshots: Finding the Leak

The RisingStack case study on hunting a memory leak in a production Node.js service provides a practical playbook:

1. Take a baseline snapshot at startup under normal load
2. Take a second snapshot after a sustained period of traffic (30–60 minutes)
3. Compare using Chrome DevTools — look for objects whose count or shallow size grows proportionally with time
4. Trace the retainer path — find the chain of references keeping leaking objects alive

A common pattern is objects referenced by a closure that has captured variables it no longer needs, or objects held in a global cache Map/Set that grows unboundedly.

clinic.js

Clinic.js is the most comprehensive open-source performance profiling suite for Node.js:

npm install -g clinic

# Detects event loop lag, memory pressure, and I/O issues
clinic doctor -- node server.js

# Focused memory/heap profiling
clinic heap -- node server.js

# CPU flame graphs
clinic flame -- node server.js

# Bubbleprof — visualizes async operations and where time is spent
clinic bubbleprof -- node server.js

clinic heap generates a heap snapshot and opens a visualizer showing which functions allocated the most memory. clinic flame generates a CPU flame graph — a top-down view of call stacks with width proportional to execution time — making it trivial to spot synchronous functions consuming disproportionate CPU time.

v8.profiler

For programmatic, scriptable profiling:

const { Session } = require('v8');
const fs = require('fs');

const session = new Session();
session.setProfilingPhase('interval');

function profile(durationMs = 30000) {
  const profile = session.startProfiling('cpu-profile', { interval: 1000 });
  
  setTimeout(() => {
    const result = session.stopProfiling('cpu-profile');
    const filename = `profile-${Date.now()}.cpuprofile`;
    fs.writeFileSync(filename, JSON.stringify(result));
    console.log(`Profile saved to ${filename}`);
  }, durationMs);
}

---

Common Memory Leak Patterns

Understanding the most frequent causes of memory leaks in Node.js applications lets you audit your codebase proactively.

Closure Leaks

Closures in JavaScript capture variables from their enclosing scope. If a closure captures a large object or holds a reference longer than intended, it prevents garbage collection of everything it references:

// PROBLEMATIC: closure captures `largeObject`
function createHandler() {
  const largeObject = allocateHeavyData(); // 50MB

  return function handler(req, res) {
    // `largeObject` is captured by this closure
    // and cannot be GC'd as long as any handler exists
    res.json({ data: process(largeObject) });
  };
}

// BETTER: extract only what you need
function createHandler() {
  const processedData = process(allocateHeavyData()); // pre-process

  return function handler(req, res) {
    res.json({ data: processedData });
  };
}

Global Caches Without Eviction

In-memory caches (Map, Set, or object registries) are a frequent leak source when eviction logic is missing:

// LEAKS: cache grows unboundedly
const cache = new Map();

function getData(key) {
  if (!cache.has(key)) {
    cache.set(key, fetchFromDB(key));
  }
  return cache.get(key);
}

// FIX: use an LRU cache with a size limit
const LRU = require('lru-cache');
const cache = new LRU({ max: 500, ttl: 1000 * 60 * 10 }); // 500 items, 10min TTL

Platformatic’s 2025 V8 GC optimization guide noted that in web applications processing concurrent requests, peak memory consumption is directly proportional to the number of concurrent requests. An unbounded cache that scales with concurrency is effectively a memory bomb.

Event Listener Accumulation

Every event listener consumes memory. Forgetting to remove listeners on request or response objects is a classic Node.js leak:

// LEAKS: new listener added on every request, never removed
app.use((req, res, next) => {
  req.on('end', () => {
    // This listener is added for every request
    // but `req` goes out of scope before 'end' fires
    // if the socket closes unexpectedly
  });
  next();
});

// FIX: use once() for one-time events
app.use((req, res, next) => {
  req.once('end', () => {
    cleanup();
  });
  next();
});

Tools like why-is-node-running or Clinic.js’s doctor mode detect accumulated listeners that should be removed.

Module-Level State

Variables declared at the top level of a module (const connections = []) persist for the lifetime of the process. If they accumulate without bounds, they leak:

// MODULE LEVEL — persists for process lifetime
const requestLog = []; // Grows indefinitely

// FIX: use a ring buffer or capped collection
const { FixedBuffer } = require('fixed-buffer');
const requestLog = new FixedBuffer(1000); // keep last 1000 only

---

Garbage Collection Tuning

Node.js’s V8 engine manages memory automatically through generational garbage collection. Understanding this system lets you tune it for your workload.

V8’s Memory Model

V8 divides the heap into three generations:

• Young generation (nursery) — newly allocated objects. Scavenge GC runs frequently and quickly, copying live objects between from-space and to-space. Most objects die young here.
• Old generation — objects that survive two or more young-generation GC cycles. Mark-Sweep and Mark-Compact GC runs less frequently but takes longer.
• Large object space — objects larger than the old generation threshold are allocated here directly.

Key V8 Flags for GC Tuning

# Increase old space (for memory-intensive apps — adjust to ~75% of available RAM)
node --max-old-space-size=4096 server.js

# Increase young generation size (for apps with many short-lived allocations)
node --max-semi-space-size=512 server.js

# Trace GC events (verbose output for diagnosis)
node --trace-gc --trace-gc-verbose server.js

# Print GC timing statistics
node --expose-gc --gc-interval=100 server.js

The --max-old-space-size flag is the most impactful for production services. By default, Node.js sets this to ~1.4GB on 64-bit systems, which may be far below the available RAM on modern servers. For a service with 8GB available and running only Node.js, setting --max-old-space-size=6144 (6GB) prevents premature OOM crashes and reduces GC frequency.

Nearform’s analysis on --max-semi-space-size found that for specific allocation patterns (typically batch-processing workloads with many short-lived objects), tuning the semi-space size from the default 16MB to 64MB improved throughput by up to 20% by reducing the frequency of scavenge operations.

GC and Event Loop Lag

GC pauses are a primary source of event loop lag. The V8 engine attempts to run GC concurrently (using background threads where possible), but stop-the-world pauses still occur during critical path operations, particularly full Mark-Compact collections.

To diagnose GC-related lag:

node --trace-gc --trace-gc-verbose server.js 2>&1 | grep "pause"

Look for lines indicating long pause times. A 2025 industry study reported that GC pauses exceeding 50ms are common during CPU saturation even in properly tuned Node.js services, highlighting that GC tuning is a complement to, not a replacement for, reducing unnecessary allocations.

Practical GC Recommendations

1. Profile before tuning — use Clinic.js to confirm GC is the bottleneck, not synchronous blocking
2. Increase --max-old-space-size to match your container/machine’s available memory minus OS overhead
3. Reduce allocations — the best GC tuning is creating fewer objects. Use object pooling for hot paths
4. Avoid promoting short-lived objects to old space — keep request-scoped objects genuinely request-scoped
5. Monitor heap usage over time — a healthy service has a sawtooth memory pattern; a linear growth trend indicates a leak

---

Performance Monitoring Tools

Optimizing performance requires continuous visibility. Here are the tools that matter in 2026:

Clinic.js

The gold standard for Node.js performance diagnostics. The clinic doctor command runs a comprehensive health check, reporting event loop lag, memory pressure, and GC statistics. Sample output flags issues with color-coded severity levels.

clinic doctor -- node server.js
# Visit http://localhost:9229 to view the interactive report

PM2 Plus / PM2 Runtime

PM2 provides process management, clustering, and a cloud APM dashboard that tracks event loop lag, memory usage, and HTTP throughput per worker process. The dashboard is particularly useful for correlating lag spikes with specific request patterns.

pm2 install pm2-runtime
pm2 plus login
pm2 start server.js -i max

Autocannon

A fast HTTP/1.1 benchmarking tool written in Node.js, ideal for load testing during profiling:

npm install -g autocannon
autocannon -c 100 -d 10 http://localhost:3000/
# -c: concurrent connections, -d: duration in seconds

0x

Flame graph generator that works out of the box without complex setup:

npm install -g 0x
0x server.js
# Opens a flame graph automatically in the browser

Prometheus + Grafana

For production monitoring at scale, export Node.js metrics via the prom-client library:

const client = require('prom-client');
const register = new client.Registry();

const httpRequestDuration = new client.Histogram({
  name: 'http_request_duration_seconds',
  labelNames: ['method', 'route', 'status_code'],
  buckets: [0.001, 0.005, 0.01, 0.05, 0.1, 0.5, 1, 5]
});
register.registerMetric(httpRequestDuration);

Scrape these metrics with Prometheus and visualize in Grafana for SLO tracking on latency, throughput, and memory.

---

Summary: Key Takeaways

1. The event loop has six phases — timers, pending callbacks, poll, check, close callbacks, plus process.nextTick() which fires between them. Know which phase your async operations run in.
2. Event loop lag is the most critical Node.js performance metric — healthy systems stay under 5ms; lag above 50ms warrants investigation; above 100ms is a production incident.
3. Synchronous CPU work is the primary performance killer — a 10% reduction in synchronous work correlates with ~15% throughput improvement. Offload CPU tasks to Worker threads.
4. Clustering scales throughput linearly with cores — for CPU-bound work, a clustered service on an 8-core machine delivers ~6.5x the throughput of a single process. Use PM2 or the built-in cluster module.
5. Memory leaks are found with heap snapshots, fixed by understanding retainer paths — compare two snapshots taken at different times under identical load. Chrome DevTools makes the retainer chain traceable.
6. Common leak patterns: closure captures, unbounded caches, accumulated event listeners, module-level state — audit your codebase for each.
7. GC tuning starts with --max-old-space-size — set it to 60–75% of your machine’s available RAM. Tune --max-semi-space-size for batch workloads with many short-lived allocations.
8. Use Clinic.js as your first diagnostic tool — clinic doctor covers event loop lag, memory, and GC health in one run.

Node.js performance optimization is a compounding practice. Each incremental improvement — eliminating a blocking operation, adding a memory cap, offloading a CPU task — feeds the next. Start with clinic doctor to find your biggest bottleneck, fix it, and repeat. By the time you’ve addressed three or four issues, your service will be performing at a level that surprises even teams who thought they knew their codebase well.

---

Sources:

• RisingStack, “Node.js Performance Analysis: Key Indicators for Driving Real Results”, October 2025 — moldstud.com
• Moldstud, “Event Loop Performance — Optimize Your Node.js Applications”, November 2025 — moldstud.com
• Platformatic Blog, “Boost Node.js with V8 GC Optimization”, December 2025 — blog.platformatic.dev
• Nearform, “Optimising Node.js: The Impact of —max-semi-space-size on Garbage Collection Efficiency”, March 2024 — nearform.com
• RisingStack Engineering, “Hunting a Ghost — Finding a Memory Leak in Node.js”, May 2024 — blog.risingstack.com
• Medium, “Node.js Performance Tuning in 2026: Event Loop Lag, fetch() Backpressure, and the Metrics That Predict Outages”, February 2026 — medium.com