How do you decide whether a long sustained run should hit scheduled and rotational work or avoid it?

## The work that only happens if you wait A run that holds a steady rate for many hours is the only test shape long enough to contain the things a system does on a timer rather than on a request. Typical inventory: - Scheduled batch and clean-up jobs, including the ones that restart or recycle a component. - Credential, certificate and key rotation, and lease or licence renewal. - Log and data-file rotation, archiving and retention sweeps. - Cache, session and token expiry sweeps, and mass invalidation at a fixed hour. - Index maintenance, compaction, vacuuming and statistics refresh. - Day-boundary rollovers in reporting and accounting. They matter for two entirely different reasons, and confusing the two is what produces a useless long hold. **They have never run while the system was busy.** Each of these paths is normally exercised at a quiet hour, by design. Rotation swapping a credential while thousands of operations are in flight, a file rotation that briefly blocks writers, a mass expiry that sends every request to the backing store at once, a maintenance pass competing for the same storage the workload is using: none of that is covered by any shorter test. **They interfere with the measurement.** A restart resets every accumulation counter to its starting value. A log rotation deletes exactly the on-disk growth being trended. A maintenance pass changes the latency distribution for an hour and pollutes any figure computed over the whole hold. ## Decide per item: arrange to hit it, or arrange to avoid it | Periodic work | What including it tests | What it does to the reading | |---|---|---| | Scheduled clean-up that recycles a component | Whether the recycle is safe while the system is loaded | Resets growth trends, flattening a real build-up | | Credential or certificate rotation | Whether the refresh path works under concurrency and in-flight work survives | A short, bounded latency excursion | | Log or data-file rotation | Whether writers block while the file is swapped | Removes the on-disk growth being trended | | Cache or session expiry sweep | Whether mass expiry stampedes the backing store | A burst of slow responses inside the window | | Index maintenance or compaction | Whether the system stays inside its limits while maintenance runs | Changes the latency distribution for that window | The decision follows from what the hold is meant to prove. A hold whose question is "does anything accumulate over a day" should exclude the recycle that resets the counters, and say so. A hold whose question is "does this survive a full operating day of everything that normally happens" should include as much of the timer-driven work as the environment can be made to run. ## Arranging the collision 1. **Enumerate the timers** with whoever operates the environment. Anything with a period shorter than or comparable to the hold is in scope, including platform-level schedules the team does not own. 2. **Decide per item**, include or exclude, from the hold's stated question, rather than accepting whatever the environment happens to do. 3. **To include, get two occurrences.** Either extend the window or shorten the configured period. Two matters: a single occurrence cannot be told apart from something unrelated that happened at the same moment, and a repeated effect with the same shape both times is attributable. 4. **To exclude, disable it deliberately and mark the result.** A trend measured with the nightly recycle switched off is a valid trend, but only if the report says so; otherwise the next reader assumes production-like conditions. 5. **Annotate the timeline.** Mark every occurrence on the result charts so that a maintenance window is not later read as a regression introduced by the release. 6. **If it cannot be disabled or moved**, record when it fired and fit growth trends on the intervals between occurrences rather than across them, stating that this is what was done. ## What either decision owes the reader - Which timer-driven work was disabled for the run, and why. - Which occurred, at what times, and what each one did to the measurements around it. - For anything excluded: that it therefore remains untested under sustained load, which is a real gap and usually a cheap one to close later with a shorter, targeted hold arranged around that single event. The failure this discipline prevents is quiet. A team runs a long hold, an unnoticed scheduled recycle happens twice inside it, the growth trend looks flat because it was reset twice, and the run is reported as evidence of stability. The evidence was destroyed by the environment mid-measurement, and nothing in the numbers says so.