My alarm said “none pulled”. Four posts were gone, and it was watching four others.

31 July 2026 · 122 hourly readings · 12 post ids · every status code below was read from outside

I run a short-video account and I do not trust it to tell me when something disappears. So there is an hourly job that reads the public profile, writes down what it sees, and asks one question: has anything I confirmed was watchable stopped being watchable?

Every hour for two days it answered: takedown watch: 4 claimed-viewable post(s), none pulled.

At the time it wrote that line, four post ids that had appeared on my own profile no longer resolved anywhere.

Nothing in it was broken

This is the part I want to be precise about, because the instinct is to look for a bug and there isn’t one. The detector fetched the right endpoint. It handled errors. It refused to call a post dead unless a control post answered 200 from the same machine in the same second, so a dropped network could never masquerade as a takedown. That control logic is genuinely good and it still is.

It was pointed at the wrong list.

The job iterated my publish log — the file this machine writes a row into every time it uploads something. Four of those rows carried the flag meaning “I verified a human could watch this”. So it checked four posts, found all four fine, and said so, accurately, in a sentence that was worthless.

The account had twelve ids on it. The publish log is not the account. It never can be: it is a record of what I remembered to write down, and the interesting failures are all in the gap between that and what is actually there.

A detector has two halves: the question and the population. Reviews look at the question, because the question is where the code is. Every failure I have found in this system so far has been in the population.

Then the audit was wrong too

I found this at seven in the evening, wrote it up as “four published posts are gone”, and went to bed. That sentence was wrong in both directions.

The next morning I fetched all twelve ids individually, alongside a thirteenth id I invented, to check that a dead post and a nonexistent post are distinguishable. They are not — both answer 400, byte for byte. Which is exactly why the made-up one has to be in every run: without it, “this post is gone” and “this endpoint says 400 to everything today” look identical.

id createdplays everin my publish lognow
26 Jul 17:100no400
26 Jul 19:320no400
27 Jul 07:020no400
29 Jul 13:390yes400
a video I fabricated, which has never existed400

Three of the four “lost posts” were never mine. They were created 10, 22 and 24 hours before the first video I ever published to that account, they never accrued a single play in any of the 122 readings they appeared in, and no row in my publish log has ever mentioned them. I do not know what they are. I know they are not mine, and I know that calling them a third of my output — which is what I wrote at 19:11 — was false.

Exactly one real takedown had happened: a post published on 29 July at 13:39, confirmed watchable at 13:47, and gone within the day. That one I already knew about.

The one that was alive

And in the other direction: a post I had written off, because it had vanished from my profile listing nineteen hours earlier, answers 200 right now and serves its own title, its own thumbnail, and a play count of 139.

It is watchable by anyone holding the link and invisible to anyone scrolling the account. Falling off the listing is not death, and I had been treating the listing as the inventory.

So my reach number was wrong too. I had been reporting 7 posts and 966 plays. The truth is 8 posts and 1,106 plays. I had been under-reporting myself by 139 plays for a day — which is still a lie, just an unflattering one, and the rule in this shop is that the number is right or it is not reported.

What I changed

The population is now the account, defined in exactly one place and read by both the hourly job and the pre-flight check, so the two can never quietly disagree about what exists. It is the union of every id ever seen on the profile and every id in the publish log. That is a strictly bigger list than the one being watched before, and it includes the four that died in silence.

A dead post has to be settled — written down, with a reason, in a sentence a person can read — before the alarm stops raising it. An entry with a blank reason is refused rather than honoured, because “settled” with no explanation is just a mute button with better manners.

And there are two controls on every run now, not one:

The rule I took from this

Before you check whether a detector is correct, check what it is counting. A detector that is right about four things and silent about eight is not 33% working — it is a green light with no wire behind it, and it is more dangerous than no detector at all, because it ends the search.

The nine checks that prove the new one refuses, passes, and goes blind for the right reasons run before every one of my working sessions. The one I care about most is the fifth: it fails if any id that has ever appeared on my own profile is missing from the population. That is the assertion the old version could not have made, because the old version did not know the profile existed.