Cooldown or debounce? Replay repeated alerts before changing the rule

Start after the condition has already produced an event

A repeated condition can generate several events before you want another notification. Deciding how to reduce those repetitions is separate from deciding whether a price crossed a threshold. This worksheet starts with an already-produced event log. It does not evaluate prices, indicators, bar closes or a platform’s trigger condition.

You supply one fixed stream label, a chronological list of event IDs and instants, a wait and an end-of-observation instant. The result shows the decisions made by two explicit rules. It can help you document a desired policy or inspect your own implementation; it does not inspect a live alert service.

Two policies answer different questions

MDN distinguishes rate limiting during continuous activity from waiting until activity becomes quiet. This page uses a leading cooldown for the first case and a trailing quiet-period debounce for the second. Those choices are deliberately explicit because implementations can also use other leading and trailing combinations.

Sources: MDN — Debounce, MDN — Throttle.

Leading cooldown uses the last emitted event

In this replay, the first event emits immediately. Its instant plus the wait becomes the next eligible instant. Events before that boundary are suppressed, and suppressed events do not move the boundary. An event exactly on the boundary is eligible. The next accepted event begins a fresh cooldown.

For example, with a 30-second wait and events at seconds 0, 10 and 40, the rule emits at 0 and 40. The middle event does not restart a new wait ending at 40; it is simply suppressed. This convention is an authored replay rule, not a claim about the settings of any exchange or notification platform.

Trailing debounce keeps the latest event in a burst

For trailing debounce, the first event starts a pending deadline one wait later. An event arriving before that deadline replaces the pending event and starts a new deadline from its own instant. A long burst can therefore keep delaying emission. The latest event supplies the identity recorded when the quiet period finally ends.

The simulation does not run a real timer. It walks your supplied chronology and compares deadlines numerically. An emission is counted only when its deadline is reached within the supplied observation horizon. Otherwise the row remains pending. Ending a file is not the same thing as waiting long enough to flush its final event.

Make equality an explicit rule

An event and a timer can share a recorded instant. This worksheet processes a due timer before an event at exactly that instant. The old pending event emits, and the arriving event begins another wait. A real event loop may use different scheduling or finer precision, so this result cannot prove what a service actually did.

Choosing event-first processing would give a different result at the boundary. Do not quietly switch between the conventions when comparing logs. Keep the wait, timestamp precision and equality rule with the exported result. If the evidence cannot distinguish the order you need, collect finer evidence or retain the uncertainty.

The clock can move backwards while the events move forwards

GOV.UK gives 25 October as the UK rollback date for 2026: clocks move back at 2am and the UK returns to GMT. In the fictional worked log, 01:59:50 with +01:00 occurs before 01:00:20 with +00:00, even though a simple clock-face sort would reverse them.

The tool requires seconds and a known offset or Z. It preserves the original timestamp and displays London local time with an offset. It neither guesses which repeated hour was intended nor checks whether the machine that produced a timestamp had an accurate clock. London is the display context; elapsed time is calculated between UTC instants.

Sources: GOV.UK — When do the clocks change?.

The worked log leaves its final event pending

A occurs at 00:59:40 UTC and B at 00:59:50 UTC. Under the 30-second debounce rule, B replaces A and becomes due at 01:00:20 UTC. C arrives exactly then. The chosen timer-first rule emits B and makes C pending until 01:00:50 UTC. Observation ends ten seconds earlier, so C is not counted.

Changing only the selected policy to cooldown yields immediate emissions for A and C. B is inside A’s cooldown. Both answers are correct for their stated rules; neither says that two real notifications arrived. The examples are fictional inputs around a verified clock-change date, not a prediction of market activity.

Completeness is an assumption with consequences

One unseen event can alter a debounce deadline or suppress a cooldown candidate. For that reason, replay is withheld unless you explicitly assume that all events for this one stream are supplied through the selected end. A blank saved reference also withholds replay. The original rows remain visible for repair.

Selecting the assumption is not external verification. A log may omit retries, events from another worker or the interval before collection began. The worksheet starts with no active timer before the first row. If your real system was already cooling down, this initial-state assumption does not describe it; preserve the earlier evidence instead of treating the first row as a fresh start.

Do not remove duplicates or sort silently

Every row needs a unique event ID, and instants must be strictly increasing. Equal instants are rejected because a row order is not proof of fine-grained execution order. A duplicate ID is not silently deleted: it may be a repeated export, or it may conceal conflicting payloads that require a separate identity audit.

The input log uses a literal pipe-separated header for a small, manually reviewed stream, not a general CSV importer. Keep references short and non-sensitive. The exported CSV retains decisions and deadlines so another reader can reproduce the same rule without being shown a screenshot alone.

Use the result to state a policy, not to claim delivery

The count is labelled replay emissions. Actual delivery count remains unknown. A later queue, network connection, device setting or delivery service can affect notifications after a policy decision. This resource does not monitor those stages, create an alert or communicate with Telegram.

Changing fields invalidates the previous result and export. The read-only worked explanation remains available without JavaScript. Use the resource first; the optional link to this site’s signals and updates offer comes afterwards and does not establish UK eligibility or the behaviour of that offer’s notification system.

Worked examples

{
  "key": "DEMO repeated condition already evaluated upstream",
  "policy": "debounce",
  "wait_seconds": "30",
  "observed_until": "2026-10-25T01:00:40+00:00",
  "stream": "complete_supplied_stream",
  "rows": "id|event_at|reference\nA|2026-10-25T01:59:40+01:00|DEMO event A\nB|2026-10-25T01:59:50+01:00|DEMO event B\nC|2026-10-25T01:00:20+00:00|DEMO event C"
}

Questions about the method

Primary sources and scope

1. MDN — DebounceChecked 2026-10-21. Debouncing consolidates closely spaced invocations and commonly waits for a quiet interval; variants can differ.
2. MDN — ThrottleChecked 2026-10-21. Throttling restricts invocation rate during continued events; leading and trailing variants exist.
3. GOV.UK — When do the clocks change?Checked 2026-10-21. 2026 UK rollback date 25 October, clocks back one hour at 2am; BST to GMT. No alert or market event is verified.

Examples explain a method. They do not predict prices or establish where a trading service is available. Check the named source before relying on future schedules.