Answer in brief

A green status tells you a job ran and exited without error. It does not tell you the job did anything. If the work has a physical residue somewhere, a queue, a folder, a table, a log, then measure the residue and not the status, because those are two different facts and only one of them is about the work. When we finally counted, the folder held 669 messages and the job had been reporting success the whole time.

Why I am writing this down

I run a fair amount of my own operation on scheduled agents now, and the thing I keep relearning is that a clean board is not evidence. This one was small and harmless and it took about two minutes to find, which is exactly why it is worth telling. The expensive version of this failure is the same shape.

What we found

I asked Brooks to go and look at two mail folders in my work mail. Read only, nothing moved, nothing marked.

One of them is where a newsletter processing job is supposed to do its work. The job is on a schedule. It had run the previous morning and reported success. Its log in the workspace had no entry for about two weeks before that.

The folder held 669 messages, and mail was still arriving in it that same afternoon.

Two things about how he counted, because they are the part I would want somebody to copy. He took every count twice, once from the mail client's own folder property and once by walking every item in the folder, and he reported both. They agreed, and that agreement is itself a result: it means nothing was filtered or hidden from the view I would have seen by eye. And he looked for the folder where processed mail was supposed to land. There is no such folder. Not empty. Not there.

The part I got wrong, which is the useful part

When that finding came back to me it had been summarized in one hop, and the summary said 669 messages, 21 unread, no reader.

Brooks caught it and pushed back on his own finding before I acted on it. Subtract the 21 unread from 669 and 648 of those messages carry a read mark. Something is reading almost all of that folder. What he had measured was that nothing files it, not that nothing reads it, and the two are not the same claim.

That distinction changes the question, which is why it mattered. A folder nothing reads, 669 deep, invites a cleanup estimate. A folder that is almost entirely read, still filling, with nowhere for processed mail to go and no log entry in two weeks, invites the real question, which is what is doing the reading and whether the job that reports success has anything to do with it. If I had costed the first framing I would have costed the wrong thing, and the number would have looked well sourced, because the count underneath it was correct.

He also told me what he could not determine. The mail system exposes no timestamp for when a message was marked read. So whether I read them in the client, or something read them and marked them, or they were marked in bulk once, all fit the evidence identically. He would not pick one, and he was right not to.

What I take from it

Two things.

The status a job writes about itself is a claim, not a measurement. If the work leaves a residue somewhere, count the residue. That check costs a minute and it is the only one that can tell you the difference between a job that worked and a job that ran.

And when somebody hands your finding on and it comes back with one extra word in it, that word is where the error is. The counts survived the summary intact. The uncertainty did not. Every retelling drops the "probably" and the "I can't tell" first, and those are usually the words doing the work.

Update, October 2026

This month we looked at how that job chooses its work, and found a way a folder can fill while its job reports success. The job picks up only unread mail, and marks each message read once it has dealt with it. So any newsletter I opened myself, just to read it, became invisible to the job. The fix is for the job to keep its own record of what it has processed, instead of trusting the read mark.

That explains how this could happen. It does not prove it is what happened to these messages. The read marks still carry no timestamp, and the job's own log stops two weeks before the count. I am leaving the open question open.