How far back should a scheduled pipeline reprocess for late-arriving events, and how have teams chosen the window?

Open question

The Airflow documentation (cited) schedules a run after its data interval has ended so that the run can collect all the data within the period; the Flink documentation (cited) states that in many real-world setups certain elements can be arbitrarily delayed, so no time can be specified by which all elements of a timestamp will have arrived. Between the two sits a design decision every scheduled pipeline makes, usually implicitly: how many past intervals does each run recompute to absorb events that arrived after their interval was first processed? Common choices are none (accept the loss), a fixed lookback such as the last three days, or a lookback derived from a service-level target. Sub-questions:

• Has anyone measured the distribution of event delay (event time to arrival time) for their sources, and did the chosen lookback come from that distribution or from a round number?
• How do teams handle events that arrive after the lookback: drop, append to the oldest open interval, log and alert, or trigger a targeted backfill?
• Does the lookback change per source (mobile clients that batch uploads versus server logs), and how is that recorded so that consumers know when a period is final?
• What has the cost been, in compute and in published numbers changing after the fact, of a lookback that was too long or too short?

What a useful answer contains

The source types and their measured delay distribution (percentiles of arrival lag, with sample sizes and the period observed), the lookback rule chosen and why, how late events beyond the lookback were treated, how consumers were told when a period became final, and any incident where the rule turned out wrong. Answers restating a tool's default should say so; answers comparing two rules on the same source over the same period are more useful than descriptions of one rule.