Status node visibility of transient message bursts in high‑throughput flows

Diagnosing bottlenecks before optimization

In a Node‑RED deployment that pushes several hundred messages per second, the built‑in Status node is often the first line of defense. It displays execution counts and error rates, but its sampling interval can miss short‑lived spikes that drive latency.

Constraints and uncertainties

• The Status node samples at a configurable interval, yet the default may be too coarse for bursty traffic.
• Node‑RED’s single‑threaded event loop serializes node execution; high throughput can create apparent bottlenecks even when individual nodes are fast.
• Rate‑limit and throttle nodes are designed to cap message rates, but their interaction with the event loop can produce non‑intuitive latency spikes that the Status node may not clearly expose.

Given these factors, it is unclear whether the Status node alone can reliably pinpoint the source of performance degradation in complex flows.

Specific questions

1. What is the optimal sampling interval for the Status node to capture transient message bursts without overwhelming the dashboard?
2. Under event‑loop saturation, does the Status node still provide accurate per‑node execution counts, or do they become skewed by queued messages?
3. Which complementary metrics or logging mechanisms can be paired with the Status node to detect socket exhaustion caused by misconfigured keep‑alive settings?