# Feature Request: Add "Random delay after last message" mode to Delay node

**URL:** <https://discourse.nodered.org/t/feature-request-add-random-delay-after-last-message-mode-to-delay-node/101982>\
**Category:** Feature Requests\
**Created:** [23 October 2026 07:16 UTC](https://discourse.nodered.org/t/feature-request-add-random-delay-after-last-message-mode-to-delay-node/101982 "2026-10-23T07:16:56Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![feixm1](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/feixm1/32/108696_2.png) [@feixm1](https://discourse.nodered.org/u/feixm1)\
**Post date:** [23 October 2026 07:16 UTC](https://discourse.nodered.org/t/feature-request-add-random-delay-after-last-message-mode-to-delay-node/101982/1 "2026-10-23T07:16:57Z")

</div>

# Feature Request: Add "Random delay after last message" mode to Delay node

## What is this idea about

Currently, the `Delay` node's **Rate Limit** mode operates with rigid, fixed intervals. For example, if the rate is set to 1 message per 5 seconds, the messages are released at precise, deterministic 5-second increments.

While this is useful for strict throttling, it doesn't allow scenarios where messages need to be passed with randomized delays between each other. Therefore, I would like to propose a new mode: **"Random delay after last message"**.

## Proposed Behavior

Instead of a fixed interval _T_, the interval between the current message and the previous one would be a random value _R_ within a user-defined range _[X, Y]_.

**Logic:**  
Let _T_{last}\_ be the timestamp when the previous message was released.  
The next message _n_ will be released at:  
`Tn = max({arrival_time}, T{last} + {random}(X, Y))`

This ensures that messages are neither sent too quickly (respecting the limit) nor sent in a perfectly periodic pattern, introducing much-needed entropy into the flow.

## Proposed UI Changes

In the Delay node configuration, when this mode is selected:

1. **Mode Selection:** A new option in the dropdown: `Random delay from last message`.
2. **Configuration Parameter:** A numeric input to define the minimum and maximum interval).

## Use Cases

- **IoT/Sensor Simulation:** Simulating real-world hardware that transmits data at irregular, non-deterministic intervals.
- **Network Traffic Emulation:** Testing how downstream services handle non-deterministic message arrival patterns.
- **Load Smoothing / Thundering Herd Prevention:** Preventing synchronized "waves" of messages from hitting an API or database simultaneously by introducing jitter, rather then fixed delay.

I tried to search for similar feature request from someone before me. I only found similar issue as [#5136](https://github.com/node-red/node-red/issues/5136) regarding the rigidity of the current rate-limiting implementation, but the discussion in my opinion was a bit off what I am aiming for. I think my solution would not need any heavy memory store but simply the last timestamp of last sent message.

I am happy to implement this and would love to hear the maintainers' thoughts on this approach before proceeding with a Pull Request. Thanks!

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [23 October 2026 08:27 UTC](https://discourse.nodered.org/t/feature-request-add-random-delay-after-last-message-mode-to-delay-node/101982/2 "2026-10-23T08:27:50Z")

</div>

Why not just use a 2nd delay node after the rate limit node?

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/c/9/c948321b4bd800d464f355868a94072e5403dede.png)

---

<div class="post-metadata">

**Author:** ![feixm1](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/feixm1/32/108696_2.png) [@feixm1](https://discourse.nodered.org/u/feixm1)\
**Post date:** [23 October 2026 12:16 UTC](https://discourse.nodered.org/t/feature-request-add-random-delay-after-last-message-mode-to-delay-node/101982/3 "2026-10-23T12:16:11Z")

</div>

That is a valid workaround for simply adding some jitter to a flow. As I mentioned, combining a Rate Limit node with a Random Delay node forces a minimum interval (e.g., `Trate+random(0,X)T\{rate} + {random}(0, X)Trate​+random(0,X))`, which prevents the user from ever achieving an interval smaller than the rate limit.

I see this as a small but meaningful tweak to the functionality already offered by the Delay node. It essentially introduces a distinction between **'delaying every message independently'** (the current behavior) and **'delaying the interval between consecutive output messages'** (the proposed behavior). Rather than requiring users to manage workarounds to approximate this, I believe implementing it natively within the Delay node would be a much cleaner and more robust solution.

As I said, I'm happy to propose a PR. I just don't want to dive into it without proper discussion.

---

<div class="post-metadata">

**Author:** ![gregorius](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gregorius/32/73816_2.png) [@gregorius](https://discourse.nodered.org/u/gregorius)\
**Post date:** [23 October 2026 13:25 UTC](https://discourse.nodered.org/t/feature-request-add-random-delay-after-last-message-mode-to-delay-node/101982/4 "2026-10-23T13:25:12Z")

</div>

> [@feixm1](#):
>
> It essentially introduces a distinction between **'delaying every message independently'** (the current behavior) and **'delaying the interval between consecutive output messages'** (the proposed behavior)

And that adds state to the node ... which isn't a minor change. Adding state to a node which is stateless is a really shame since statelessness is far simpler to handle than maintaining states all the time.

Is there a alternative of creating a custom delay node in a custom package? If the node hasn't yet got any state information, then changing that is something for a custom node package perhaps.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [23 October 2026 13:53 UTC](https://discourse.nodered.org/t/feature-request-add-random-delay-after-last-message-mode-to-delay-node/101982/5 "2026-10-23T13:53:57Z")

</div>

> [@gregorius](#):
>
> that adds state to the node

Does it not already have state for the mode rate limit with queueing?

---

<div class="post-metadata">

**Author:** ![gregorius](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gregorius/32/73816_2.png) [@gregorius](https://discourse.nodered.org/u/gregorius)\
**Post date:** [23 October 2026 14:07 UTC](https://discourse.nodered.org/t/feature-request-add-random-delay-after-last-message-mode-to-delay-node/101982/6 "2026-10-23T14:07:21Z")

</div>

> [@Colin](#):
>
> Does it not already have state for the mode rate limit with queueing?

Me not know, if the state is already there then what I said becomes stateless, i.e. irrelevant.

I was just pointing out that the suggested behaviour would require state for each delay node.

But by the sounds of it, you're right - for rate limiting it will probably already have state.

---

<div class="post-metadata">

**Author:** ![feixm1](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/feixm1/32/108696_2.png) [@feixm1](https://discourse.nodered.org/u/feixm1)\
**Post date:** [23 October 2026 16:13 UTC](https://discourse.nodered.org/t/feature-request-add-random-delay-after-last-message-mode-to-delay-node/101982/7 "2026-10-23T16:13:24Z")

</div>

You are absolutely right. The `rate limit` mode already manages state through its queue and timing mechanisms to ensure messages are released at the correct intervals.

My proposal doesn't aim to introduce a fundamentally new kind of state, but rather a different logic for how that existing timing state is calculated. Instead of using a deterministic, fixed interval for the next release, we would use a stochastic one.

Essentially, we are not adding new complexity to the node's architecture, but simply providing an alternative mathematical rule for the scheduling logic already present in the `rate limit` implementation. This allows users to achieve jittered arrival patterns without the need for extra nodes or manual workarounds.