112 Scheduled Jobs, and How Many Really Ran

What was broken

My operating system runs on scheduled jobs. Each job is a written set of steps that an AI agent carries out on a timer. Some write content. Some check my websites. Some remind me of things.

In August I went looking for one important job and found a whole folder instead. It held 112 of them. They were not in my computer's own scheduler. They were not in my cloud task list either. No audit had ever opened that folder.

So I asked a simple question. Of these 112 jobs, how many really run?

The answer was worse than I thought. Only 66 showed any proof of running. 24 had been seen just once, in a single listing session, and never in an actual run. 3 had never appeared anywhere at all. The rest were either rare or had gone cold months ago.

There was a second problem. 25 of the jobs were one-time jobs, meant to fire on a set date and then finish. 24 of them were still on the list. The oldest was 94 days late.

And almost no job wrote down that it had run. On the first day, only 1 of 112 did. So the list told me what I had planned. It did not tell me what had happened.

What I built

I built a small record in a single database file. It holds every job, the group it belongs to, and whether there is proof it ran.

The main rule is simple. A check must give a number, not a label. Not "fine" or "broken", but 61 of 112. Then I can see if it moves week to week.

I added one tiny helper that any job can call at the end of its run. It writes one line: this job ran, at this time. No setup needed.

Then I set up a weekly check that counts again from the files themselves, and sends me one line if anything got worse.

While building this, I kept tripping on the same thing. Five times in one day, "I could not look" came out as "I looked and found nothing." A check that could not open a folder reported zero out of zero, and marked it a pass. At one point 11 of 15 checks could do this. I fixed each one so that a blind check now says it is blind.

I also found that my first weekly check had never once worked on its schedule. It ran in the cloud, and a cloud job cannot reach the files on my computer. It fired, did nothing, and looked fine.

That led to one more find. There were 10 more jobs in the cloud, outside the folder. The true total was 122, not 112. I added them to the record. But I count them apart, because they can never write to my computer. Counting them in would make that number fail forever.

What changed

In 2 days, jobs that record their own runs went from 1 to 6. It is still a small number. But it is now a real number that I can watch climb.

61 of 112 jobs showed a run in the past 7 days. For the first time, I know which ones did not.

I did not switch anything off. I ruled that we build the record first and fix after. Stopping five problems without a record just hides the next five.

What I would do differently

I would make every job write one line when it runs, from the very first job. It costs almost nothing. Adding it later to 112 jobs costs a lot.

I would give every one-time job an end. A job that should have finished and did not is a small risk that grows quietly.

I would treat any sentence with "never" or "zero" in it as a claim to test, not a fact. Mine were wrong more than once.

And I would match jobs by their fixed ID, not their name. When one job was renamed, my count showed 123 instead of 122 for a while. The job had not doubled. My counting had.