Webbu Docs

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 s

Without maxWaitFromFirstMs, a steady trickle like this would be delivered only when the group reached maxItems.

Choosing values

ScenarioSuggested batchWhy
Near real-timeidleTimeoutMs: 1000, maxWaitFromFirstMs: 5000Small batches, low latency
Chat/conversation burstsidleTimeoutMs: 3000, maxWaitFromFirstMs: 30000Captures a whole burst of messages
Cost reduction for automation toolsmaxItems: 100, idleTimeoutMs: 60000, maxWaitFromFirstMs: 300000Few, large batches
Large payloadsmaxBytes: 1048576 with a lower maxItemsKeeps 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.

On this page