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

Short answer

No — the Status node alone is not a reliable detector of transient bursts at several hundred messages per second. It is a dashboard widget that samples status changes at a fixed interval (1 second by default), so spikes shorter than the sampling window are averaged away before you ever see them. It remains useful as a coarse health indicator, but burst diagnosis requires pairing it with per-message timing instrumentation.

What the Status node actually does

The Status node reflects the node.status() calls made by the nodes it targets. Those status updates are pushed to the editor/dashboard on a poll or push cycle, not per message. Two consequences follow:

• Counts are per-node accurate, but display is lossy. If a node updates its status 500 times in a second, the dashboard shows the last sampled value, not 500 distinct updates. Under event-loop saturation the underlying counts are still correct, but what you see lags and can appear skewed because queued messages update status in bursts when the loop frees up.
• It sees nothing about sockets. The Status node has no visibility into TCP connection state, keep-alive timers, or file-descriptor usage, so socket exhaustion will never appear there directly.

Answering the three questions

1. Optimal sampling interval

There is no universally optimal value; the trade-off is resolution versus event-loop load. A practical starting point is 100–250 ms for burst investigation, then reverting to 1 s for steady-state monitoring. Be aware that the status updates themselves run on Node-RED's single-threaded event loop, so very aggressive intervals can worsen the latency you are trying to measure. Verify the setting is not distorting results: temporarily disable the Status node and confirm end-to-end latency improves measurably — if it does, the monitor is part of the bottleneck.

2. Accuracy under event-loop saturation

Execution counts remain accurate at the node level, but two caveats apply. First, display latency grows because status messages queue behind work messages. Second, if an upstream rate-limit or throttle node drops messages (rather than delaying them), those messages never reach downstream nodes, so downstream Status counts will under-report the true offered load. Compare counts at the flow entry point against counts after any throttling node to quantify drops.

3. Complementary metrics for socket exhaustion

• Per-message timestamps: a small function node that records Date.now() deltas between consecutive messages into flow context exposes sub-second burst structure the Status node cannot.
• Prometheus export: a contrib module such as node-red-contrib-prometheus (or a custom endpoint) gives you histograms and rates you can alert on, offloading aggregation from the event loop.
• OS-level socket inspection: for keep-alive misconfiguration, watch connection states directly:

ss -tan state established '( sport = :1880 )' | wc -l
ss -tan state time-wait | wc -l
ls /proc/$(pgrep -f node-red)/fd | wc -l

A steadily climbing TIME_WAIT count or file-descriptor total approaching the process limit is the classic signature of keep-alive or connection-reuse problems — and none of it surfaces in the Status node.

Verification recipe

Set the Status interval to 100 ms, inject a controlled burst (for example 200 msg/s for 5 s via an inject node), and confirm the dashboard spike matches the injected rate. Then compare against a function-node counter written to flow context; discrepancies indicate queuing or sampling loss rather than real throughput changes.

Caveats

Exact defaults and status-delivery behavior vary across Node-RED versions; confirm against your installed release (check settings.js and the release notes) before tuning production flows. The socket commands above assume Linux.