Your per-user download threshold came from four weeks of data and now fires every quarter-end. Why?

## What actually went wrong A derived threshold is a summary of a sample. If the sample is four consecutive ordinary weeks, the summary describes ordinary weeks, and any recurring event with a period longer than four weeks is outside it by construction. Quarter-end reporting, month-end close, the annual audit, an offsite, a product launch, term start in a university, open enrolment in a benefits system — every estate has cycles, and a baseline window shorter than the cycle guarantees the cycle looks like an anomaly, forever, on schedule. This is a distinct failure from cold start. Cold start is an *empty* baseline. Seasonality is a *full* baseline built from an unrepresentative period. Both produce floods, but the cure is different: cold start needs time, seasonality needs a longer or better-structured window. ## Three ways to handle a cycle **Widen the derivation window.** The simplest fix: derive the threshold over a period that contains at least one, preferably several, instances of the cycle. A year of history to catch a quarterly pattern. The cost is that a long window blurs genuine drift — a team that doubled in size six months ago is still being compared against its smaller self — so long windows usually need decay or periodic re-derivation. **Compare like with like.** Rather than one threshold per entity, hold a baseline conditioned on the period: this account on quarter-end days against this account on previous quarter-end days; this account on a Monday against its own Mondays. This handles the cycle without discarding sensitivity on ordinary days, and it is often cheap, because the conditioning is a grouping key rather than a model. **Handle it as a known exception.** Where the cycle is driven by a small, identifiable group — a finance team, a reporting service account — the honest answer may be that those entities need their own logic or their own thresholds, not that the whole rule needs loosening. Do not let one predictable department set the sensitivity for the other ten thousand accounts. ## The trap: do not go blind on the busy day Seasonal handling has an adversarial edge that a purely statistical treatment misses. A predictable busy period is an advertised hiding place. If quarter-end raises everyone's expected volume by a factor of five and nothing else changes, the sensible move for someone collecting data is to do it at quarter-end. So the widened expectation should not be an off switch: - keep an absolute cap live regardless of the period, so *some* volume is always remarkable; - keep the qualifying conditions live — an unfamiliar client, a session from an address the account has never used, activity by an account with no business reason to be in the cycle; - and check *who* is spiking. Finance spiking at quarter-end is expected; an engineer in a different business unit spiking on the same day is not covered by the seasonal explanation at all, even though the calendar says it is a busy period. That last check is the one candidates most often miss. A seasonal allowance should apply to the entities the season actually explains, not to everybody who happens to share the date. ## Re-derivation, and the poisoned window Baselines age. Headcount changes, a new application rolls out, a team adopts bulk export, a service is retired. A threshold derived once and never revisited drifts into either constant noise or complete silence, and silence is the failure you will not notice. So re-derivation belongs on a schedule with an owner. But re-derivation carries its own hazard: if you rebuild the baseline from a rolling recent window and that window contains the activity you were trying to detect, you have just taught the rule that the activity is normal. A slow ramp is particularly good at this, because each refresh only has to absorb a small increase. Two defences: prefer to rebuild from a period you have some evidence was clean, and keep at least one long-horizon comparison — total volume this quarter against the same quarter last year — that a gradual ramp cannot escape by being gradual. ## The interview answer Name the cause in one sentence: the derivation window did not contain the cycle, so the rule learned an unrepresentative normal. Offer the like-for-like comparison as the better fix over simply raising the number. Then add the adversarial half — that a known busy period is a known hiding place, so seasonal allowance widens the expectation for the entities the season explains and never turns the rule off — and the re-derivation hazard of baking recent malicious activity into the new normal.