Use the Jitter node to mimic human sending cadence
The Jitter node picks a random delay in a range each time the flow reaches it, so consecutive sends don't share an identical timing signature.
What it does
The Jitter node is identical to the Delay node in one respect: both pause the flow before continuing. The difference: Delay always waits the same duration. Jitter picks a random duration inside a range you set, every time the flow reaches it.
This matters because WhatsApp's spam classifier watches timing patterns. A flow that always waits exactly 30 seconds between two steps is a perfect timing fingerprint. Multiply that across 1,000 recipients and the classifier sees a server, not a human.
When to use it
- Between two send-message steps in a marketing flow
- Inside a campaign so per-recipient send intervals don't all share the same delay
- After a "Wait for Reply" node before the auto-response, so replies don't go out at robotic-fast speeds
- Anywhere you'd otherwise put a fixed Delay in a flow that runs at scale
When the regular Delay is fine
- One-off "wait one hour after order is placed before checking in" where the absolute timing matters more than the variance
- Flows that only run for a single user (low volume, no fingerprint risk)
- When you specifically want a predictable delay (e.g., regulatory waiting periods)
How to add it
1. In the flow builder, drag the Jitter node from the palette.
2. Connect it between two existing nodes.
3. Click to configure:
- Min: lowest possible delay (e.g., 10)
- Max: highest possible delay (e.g., 60)
- Unit: seconds, minutes, or hours
4. Save the flow.
Each time the flow reaches the node, it picks a fresh random integer in [min, max] and waits that many units before continuing.
How it behaves under the hood
The Jitter node uses the same persistence and crash-recovery machinery as the Delay node. If the worker process restarts mid-wait, the resumption is reliable: when the chosen delay expires, the next step fires.
If your BullMQ Redis instance briefly goes down, the worker falls back to in-memory setTimeout for that one execution, so flows don't stall.
Recommended ranges by use case
| Use case | Min | Max | Unit |
|---|---|---|---|
| Conversational flow between two send steps | 5 | 30 | seconds |
| Marketing campaign per-recipient pacing | 15 | 60 | seconds |
| Re-engagement sequence (one message a day) | 18 | 30 | hours |
| AI reply latency (so replies don't feel instant) | 2 | 8 | seconds |
Common questions
Does jitter affect message delivery?
No. Once the wait completes, the next step runs normally. The only effect is timing.
Can I use Jitter and Delay in the same flow?
Yes, freely. They're independent nodes. Use Delay where the duration matters, Jitter where the variance matters.
Does Jitter work with all transports?
Yes. It pauses the flow itself, regardless of whether the next send is via Walytic Web or Walytic Cloud.
Need more help?
Browse the rest of the help center or contact support directly.