Flush Conditions
Configure when buffered webhooks are delivered, by count, size or time.
Overview
Flush conditions decide when a group is delivered. Every buffer has all four in its batch settings, and a group is delivered as soon as any of them is met:
{
"batch": {
"maxItems": 50,
"maxBytes": 262144,
"idleTimeoutMs": 5000,
"maxWaitFromFirstMs": 15000
}
}The values above are the defaults. They balance three things:
- Latency: how long an event waits before reaching your endpoint
- Batch size: how many events each delivery carries
- Cost on your side: fewer deliveries mean fewer invocations, tasks or operations
The conditions
maxItems
Deliver as soon as the group has this many items. Reaching it triggers a delivery right away. It is also the maximum number of items in one delivery.
Use it when your consumer works best with a fixed batch size, or to cap how big a batch can get.
maxBytes
Deliver when the group's payloads add up to at least this many bytes (default 256 KB). It is evaluated at each scheduled flush check (see below), so a group can go somewhat past it before it is delivered. For a hard limit per batch, use the overflow limits.
Use it to keep batches within your endpoint's request size limits.
idleTimeoutMs
Deliver when no new item has arrived for this long (minimum 100 ms).
Use it for bursty traffic: wait until a burst is over, then deliver it in one request. This is usually the main setting.
maxWaitFromFirstMs
Deliver when the oldest item in the group has waited this long, even if items keep arriving (minimum 100 ms).
Use it as a latency guarantee: with steady traffic the idle timeout never expires, and this condition still forces regular deliveries.
How checks are scheduled
When the first item enters an empty group, Webbu schedules a check for idleTimeoutMs later. At each check it delivers the group if maxItems, maxBytes, maxWaitFromFirstMs or the idle timeout is met; otherwise it schedules the next check for whichever of the idle deadline and the max-wait deadline comes first. When an item makes the group reach maxItems, a check runs immediately.
Example timeline
A buffer with idleTimeoutMs: 3000 and maxWaitFromFirstMs: 10000 receives items for one group at 0, 1, 3, 5, 7 and 9 seconds:
time (s) 0 1 2 3 4 5 6 7 8 9 10
items ● ● ● ● ● ●
idle never 3 s without an item, so the idle timeout never fires
max wait ├──────────────────── 10 s since first item ──────┤ → deliver at 10 sWithout maxWaitFromFirstMs, a steady trickle like this would be delivered only when the group reached maxItems.
Choosing values
| Scenario | Suggested batch | Why |
|---|---|---|
| Near real-time | idleTimeoutMs: 1000, maxWaitFromFirstMs: 5000 | Small batches, low latency |
| Chat/conversation bursts | idleTimeoutMs: 3000, maxWaitFromFirstMs: 30000 | Captures a whole burst of messages |
| Cost reduction for automation tools | maxItems: 100, idleTimeoutMs: 60000, maxWaitFromFirstMs: 300000 | Few, large batches |
| Large payloads | maxBytes: 1048576 with a lower maxItems | Keeps request bodies manageable |
The dashboard form limits these fields to: maxItems 1 to 10,000, maxBytes 1 KB to 10 MB, idleTimeoutMs 100 ms to 5 minutes and maxWaitFromFirstMs 100 ms to 10 minutes.