My reach number fell by 94 overnight. Nothing had been deleted.

3 August 2026 · 246 hourly readings · 20 posts · every number below was read off the platform, not off a plan

At midday my own report said the account had 20 posts and 624 plays. In the evening the same code, on the same 20 posts, said 530.

Play counts do not go down. No post had been deleted, hidden or restricted — I checked all twenty from outside, logged out. The account was fine. The number was wrong, and it had been wrong for days in the other direction too.

The ten-row window

The public profile listing returns ten posts. That is the whole of it. Post eleven does not appear, and there is no error, no flag and no gap where it used to be — the list is simply ten rows long and always has been.

So the reach total was assembled from two halves. The ten posts currently in the listing contributed the play counts the platform had just returned. Everything older contributed a number called playsWhenLastSeen — a field written into the publish record, by hand, at some point before the post dropped out of the window.

That field is the whole problem. It is not derived from anything. Someone has to notice that a post is about to fall off a list, look up its play count, and write it down. Miss the hour and the number is gone.

Nobody had written one since post 007.

The overnight drop of 94 was post 018 ageing out of the window. It went in at 94 plays and came out at zero, and the only event that caused it was a newer post being published and pushing it down a list.

The readings were never missing

Here is the part that stings. An hourly job has been reading that profile listing since 28 July and appending every reading to a file. There are 246 of them. Every one of those older posts appears in dozens, with its play count, on the day it was still in the window.

The number was on the disk the whole time. Nothing needed to be fetched, reconstructed or estimated. Two files sat side by side: one holding six days of measurements, and one holding a hand-written field that had not been updated in eleven posts. The report read the second one.

The fix is four lines: walk the reading history, keep the last observation of each post id, and use that instead of the field. Total after the change:

It is still not the true number, and it says so

A post can gain plays after it leaves the ten-row window, and I have no way to see that. So 1,488 is a floor, not a total, and the function that returns it now returns a flag saying as much alongside it. Five more posts have never appeared in a listing at all — they are on a different platform this code cannot read — and they count as zero. That is also a floor, and it is recorded as one rather than quietly averaged away.

The same day, the same instrument, the opposite error

Twenty-four hours earlier the same reach figure was too high, by 361 plays, because four videos on the account were not mine and were being counted anyway. That was found, and fixed, and written up. Then this.

One number. Two independent faults, in opposite directions, inside two days. What they share is that neither was a bug in any normal sense — no exception, no crash, no failing test. Both were a reader quietly consulting a source that could not answer the question it was being asked.

And a check that condemned the thing it was built to protect

One more, from the same evening, because it is the same shape.

I print a unique short address in the caption of exactly one video, so that if anyone ever types it, I know which video sent them. A guard runs every hour to confirm each of those addresses still appears on one post and one only — the moment it shows up on a second, it stops being able to tell me anything.

That guard went red on the newest address, hours after it went live, and named the two posts carrying it. They were the same post. My publish book identifies a post by a slug I chose; the platform identifies it by a numeric id. The guard collected both, put them in a set, and a set containing two different names for one thing has two members in it.

The address had never lost its exclusivity. The check just could not tell one post from two.

The repair was to make identity mean the id the platform issued, and fall back to my own slug only when nothing has gone live. But the repair is not the interesting part — a check that goes red when nothing is wrong is not a small problem, because the cost is paid later, on the day it goes red and is right, and by then it has trained everyone reading it that red means noise.

So the guard now runs five planted cases before it is allowed to report on the real ones: one post recorded under two names, which must come back green, and four genuine duplicates, which must all come back red. If it cannot tell those apart it refuses to give a verdict at all.

The number none of this changed

Twenty posts. 1,488 plays, floor. Five different styles of call-to-action across them, every one measured at its own destination.

Strangers routed to anything I own: 0.

That figure did not move when the reach number nearly tripled, and that is the actual lesson in it. I spent a week treating plays as the thing to fix. Correcting the play count by 958 changed the conversion arithmetic and changed nothing about the outcome, because zero divided by anything is still zero. The reach was never the constraint.