Measured over a week, your event lateness distribution is p50 1.2 seconds, p99 45 seconds and p99.9 11 minutes, with a tail from mobile clients that buffer offline. An hourly tumbling aggregate holds the watermark 60 seconds behind the newest event. Roughly what share of events does it drop, and what would moving the hold to 11 minutes actually buy?

The assumptions, stated

The lateness figures come from a histogram of arrival time minus event time measured in production over a week, which is the only way to get them. Events are spread roughly evenly through the hour. A window covering [0, W) closes when the watermark passes W, which happens H after the newest event time, where H is the hold. An event with event time t and lateness L arrives at t + L and is dropped only if t + L > W + H.

The arithmetic

Rearranged, the event is dropped when t > W + H - L, which is possible only if L > H, and then it covers a slice of the window of width L - H. Averaged over a uniformly distributed event time:

drop fraction ≈ E[max(0, L - H)] / W

The expected excess lateness over the hold, divided by the window size. Taking the distribution above: about 0.8% of events land between 60 seconds and roughly 5 minutes late (mean excess around 90 seconds), about 0.1% around the 11-minute mark (mean excess around 420 seconds), and about 0.1% beyond it (call it 1200 seconds).

E[excess] ≈ 0.008 × 90 + 0.001 × 420 + 0.001 × 1200 ≈ 2.3 seconds.

Against an hourly window: 2.3 / 3600 ≈ 0.06% dropped. Raising the hold to 11 minutes cuts the expected excess to roughly 0.6 seconds, so the loss falls to about 0.017%. Eleven minutes of added latency on every hourly result buys four hundredths of a percentage point, and costs the open-window state and the downstream freshness for all of it.

What the number rules out

The same distribution against a one-minute window gives 2.3 / 60 ≈ 3.9% dropped at a 60-second hold, falling to about 1% at an 11-minute hold. This is the arithmetic behind every "the streaming total is a couple of percent under the batch total" reconciliation argument: the loss is not a property of the lateness distribution alone, it is the lateness distribution divided by the window.

The decision rule

Pick the hold from the error budget and the window, not from a lateness percentile: choose H so that E[max(0, L - H)] / W is inside the tolerance the consumer of the number has already agreed to. Short windows need either a long hold, an allowed-lateness update path that re-emits corrected results, or a separate side output for late events that someone reconciles.

Which assumption dominates the error: the shape of the tail beyond p99.9. The mean excess is driven by the rare 20-minute arrivals, not by the 46-second ones, so a distribution summarised only by p99 cannot answer this question at all, and sizing from p99 is the common way this fails silently. Measure the tail in buckets out to hours.

When this is the wrong answer

If the consumer is a financial figure somebody signs, the error budget is zero and none of this applies: emit provisionally, keep the window open against a late-data side output, and publish a correction. The estimate above decides how long to wait, not whether the number may be wrong.