Running the job, not just the clock
We proved our scheduled jobs fire at the right minute, every minute of a week. That is not the same as proving they work. Two of them had never been executed by anything, and the gap is invisible from outside.
Every hospitality system ends up with a drawer of jobs that run on their own: the nightly figures, the overdue-ticket nudge, the thing that tidies up last month. Nobody presses a button for any of them. Which means nobody notices the day one stops.
We hang twelve jobs off a clock that ticks every minute, most of them gated to a single minute of the hour, the day or the week. So we did the obvious thing and proved the clock: ran the dispatcher for every minute of a simulated week and counted what it handed out. The hourly ones fired 168 times, the daily ones seven, the weekly one once, and never two heavy jobs on the same minute.
That was worth doing and it proved less than it looked like it proved.
Reaching a job is not running it
All that test establishes is that the right door gets knocked on at the right time. What happens behind the door is a separate question, and for two of our twelve the honest answer was that nothing had ever opened it.
One of them turned out fine. The other had a real fault underneath it — a piece of caching that, if it ever failed once when the system started, would keep failing for as long as that instance lived, replaying the same stale error instead of trying again.
The last of the twelve was the one that moves pre-orders onto the kitchen screen. A checking tool had been matching it by a single word in the source, which is a way of confirming that some code is present, not that it does anything. We have now run it against a real database, and it is correct.
Where would you see it?
The companion question to did it run is where would I look. For most of our jobs the answer is a row somewhere: a nightly rebuild leaves a timestamp, a status check leaves a reading. One left nothing at all. Its entire output was a line in a log, and logs are not kept — so once the screen scrolled, a job that had quietly stopped looked exactly like a job that ran and found nothing to do.
It writes a row now. The first one landed this morning at eight minutes past four, which is also the first time we could prove the change worked at all: a job that only runs once a day cannot be demonstrated the moment you ship it, and saying otherwise would be describing an intention.
The operator version of this
You have automated things too — a stock count that rolls over, a report that emails itself, an integration that syncs overnight. For each one, ask where you would see evidence that it ran this morning. If the answer is that you would notice when something looked wrong, you do not have a check. You have a delay.