The day your automation thinks it is
Three percent of runs land on the wrong day
Since August 9 the jobs on this machine that are pinned to a specific weekday have logged 538 runs. Eighteen of those ran on a weekday they were not scheduled for, spread across 13 different jobs. A little over 3 percent.
Nothing exotic caused it. The machine was asleep at 3 AM and the job caught up when it woke, or something restarted, or I kicked one by hand to check something. Every one of those is normal and none of them is going away.
So the number to carry into anything you automate is this. A scheduled job will eventually run on a day it was not written for, and the ones that handle it badly do not crash. They finish on time and stamp the wrong date on their work.
Counting forward drifts, anchoring does not
The difference between a job that survives a catch-up run and one that mislabels a month of output is usually a single line of date math. A job that computes its target as today plus seven days is correct on exactly one weekday, the one it was written for. Run it a day late and it names a Friday when it meant Thursday. Fire it during a boot catch-up on Monday morning and it names next week.
The version that holds up asks the calendar instead of the clock. Today or the next Thursday, derived from the weekday, gives the same answer whether the job runs at 3:20 AM Thursday as intended or at 9 AM Friday after a restart. The jobs here that publish anything with a date on it use that form, and they are the ones nobody has had to go back and correct.
Wrong-day output costs more than it looks like it should, because a date is the part people trust without reading. A weekly summary labeled with the wrong week gets filed as the wrong week. A customer note that says this week's schedule is read as this week's schedule. The body can be entirely correct and the label still walks somebody into the wrong decision.
The written schedule drifts from the real one
There is a second version of this that involves no code at all. This morning I compared every job here whose written instructions name the day it runs against what the scheduler actually holds. Thirty jobs state a day in writing. Six of them name a day the machine does not use. One document says Friday and the entry runs it Saturday. One says Saturday and the entry says Wednesday.
None of those six are broken. They run on time, every week, on the day the machine says. The damage lands on the person reading the procedure. You go looking for Friday's output on Friday, do not find it, and start debugging a job that was never going to have run yet. Or you plan a change around a day that is not the day.
Documents go stale the first time somebody edits a schedule and not the write-up, and there is no error message for that. The scheduler is the record. Everything written down is a copy, and copies need checking on a set interval.
What this looks like at one automation
You do not need dozens of scheduled jobs for any of this to bite. One automation that emails a weekly update to customers is enough.
Ask whoever built it where the date comes from. Derived from the calendar target is the answer you want. Counted forward from whenever the job happens to run is the one that drifts, and it will look fine for months because most runs do land on the intended day.
Then have the job say the date out loud. A run that records both the day it fired and the period it claims to cover turns a silent mislabel into two numbers sitting next to each other. When they disagree, you know you are looking at a catch-up run, and you can decide whether the output stands or gets regenerated before anyone outside sees it.
Once a quarter, read the schedule out of the machine rather than out of your notes, and compare the two. It takes an afternoon at most, and it is the only way to catch the kind of drift that lives entirely in the documentation.
The same assumption, twice
Running on the wrong day is the near relative of running twice. Both come from assuming the schedule will be honored exactly as written, both are cheap to handle before launch, and both are tedious to clean up after a quarter of mislabeled output.
Checking date handling across everything you already run is part of an AI ops audit. Catching the week the scheduler and the written procedure stopped agreeing is the month to month side of the work.
The audit answers this for your business
Two weeks, $2,500 flat ($1,000 for the first three clients), and you get the map of your own automatable work with dollars on it.