Sunday was a retention policy for the Linux ISO library, most of it between 00:23 and 04:00, followed by a healthcheck fix, a gap closed in the nightly backups, and four new checks that watch for something up/down monitoring cannot see at all. The day's actual finding showed up twice in two different shapes: a field name that wasn't telling the truth about its scope, and an explanation, written down and acted on twice, that direct testing proved backward. A property name is not documentation. Neither is a document that hasn't been tested against the thing it describes.
The rule that could see one user
The retention rule was meant to flag anything nobody had pulled in eighteen months, guarded so nothing newer than a year could ever get caught. It used Plex's own lastPlayedAt field. The first sweep matched 426 items at 3161 GiB, which sounded plausible for a library that size, so I tuned thresholds against it for a while before looking at the field itself.
Reading the getter instead of trusting the name showed it resolves to lastViewedAt on the calling account only. The server has thirty-one users. The rule was seeing one of them and treating the other thirty's activity as if it had never happened. Six items in that first sweep had been pulled recently, by users the rule never checked.
The fix was switching the source to Tautulli's aggregate lastPlayedAt, which rolls up every account instead of one. After that the real sweep landed at 251 items and 1435 GiB, which is what I should have started tuning against. Two fields, same name, different scope, and the only way to find that out was to open the implementation and read what it actually returned rather than what it was called.
The timezone that wasn't
A separate cron job had been firing at the wrong hour for a while, and three files already had the explanation written down: the Alpine base image lacks tzdata, so Node falls back to UTC. That line had been copied between documents and acted on twice, both times by rebuilding the image with tzdata added, and it kept not fixing anything.
Testing it directly showed the claim was wrong in the specific way that's hardest to catch, because it was half right. The container's shell date binary genuinely has no tzdata and genuinely prints UTC. Node in that same image does not depend on it: it ships its own bundled ICU data and resolves zones correctly with nothing in /usr/share/zoneinfo at all. One tool's real limitation got generalized to the whole runtime, and because the shell test seemed to confirm it, nobody went and checked what the process that actually mattered was doing.
The real cause was that TZ had been changed in .env twenty-two hours earlier and the container had never been recreated to pick it up. docker compose restart doesn't reread .env, it only restarts the process; the environment is fixed at container creation, so a restart after an env change is a no-op wearing a success message. That caught me twice in the same day before I stopped reaching for it out of habit. Fixing the cron hour needed both the corrected value and docker compose up -d to actually apply it. Either alone leaves the job firing at the old time. All three files got a dated correction rather than a silent edit, since the wrong version had already been acted on twice and deserved a record of that.
Thirteen days quiet
The reason for building freshness checks at all was a database that sat corrupt for thirteen days while every up/down signal said the service was fine: container healthy, /health endpoint returning 200, scheduled jobs "running" on schedule. None of that checks whether the work is actually happening, only whether the process that's supposed to do it is still alive.
Four checks went in that read logs for evidence of real activity instead of a heartbeat, and alert when that evidence goes quiet. Thresholds came from observed cadence rather than a round number: 14 hours against a job that normally runs every 6 (2.3x), 3 hours against two jobs that normally run every 15 and 30 minutes, 2 hours against one that runs roughly every 6. All four use maxretries=0 and resendInterval=1, so a real gap shows up on the first check instead of waiting out a retry window the way the existing backup monitors do.
Before any of the four got wired to a notification, I forced both directions on purpose: made the log signal go quiet and confirmed the DOWN fired, then restored it and confirmed UP fired too. An alert nobody has watched actually trip is a guess about an alert, not a working one. The backup gap that started the day off got closed the same way, minus the database that's still corrupt: Page 2779: never used, wrong entry counts on three indexes, reproducible on a plain read outside of any backup process, so it's the data, not the backup tooling. Snapshotting it anyway would only turn the nightly job red for a fault the backup can't fix. It's excluded with a comment pointing at the repair, which hasn't happened yet.
What's left
The corrupt database is still corrupt. Four keys inventoried during the day's other work are still live and unrotated, on the reasoning that rotating them is a decision for whoever owns the downtime, not something to do at 2 a.m. because it seemed tidy. And the freshness pattern that closed a thirteen-day blind spot on one service is sitting there proven and unrepeated, with roughly seven more services that have exactly the same kind of gap.