I went looking for this laptop's crontab to write a comparison with systemd timers, and there wasn't one. No crontab binary, no /etc/cron.d, no cron daemon running at all — crontab -l just says command not found.
CaRMen, the CRM I built for myself, now runs as two public sites: the real instance and a demo. Public means bots find the login endpoint within hours, so in October I added rate limiting to logins and to password-reset emails. The limits themselves took a few lines of Symfony configuration.
A freshly upgraded database reported itself perfectly healthy, right up until every other service that needed to talk to it got a flat connection refusal. The database wasn't lying about being healthy. It genuinely was — to itself, and to nothing else.
The version of a database upgrade that fits on a disk with limited free space and the version of a database upgrade that keeps a true instant rollback available turned out to be two different operations. Choosing the one that actually fit meant giving up the other, deliberately, with the tradeoff written down plainly rather than discovered the hard way if it were ever needed.
A search engine's core ranking signal sat at zero for every single page in the corpus, fleet-wide, for 29 days. Nothing crashed. No error fired. The number that determines how results get ordered was simply wrong, silently, for a month, until someone went looking for a different reason entirely and found it by accident.
For about a day in August, the Postgres server behind my search engine kept dying. Not slowing down, not timing out: the Linux OOM killer was terminating it, roughly every 20 to 90 minutes at the worst point, and each kill meant a crash-recovery cycle of about 90 seconds while Postgres replayed its write-ahead log.
A database upgrade tool refused to run, complaining about two disks that don't exist. The two volumes it was pointed at were sitting on the exact same physical disk. The error was correct anyway — from the tool's own point of view, they might as well have been on different planets.
Keeping thirty days of database backups sounds conservative. Nobody had actually multiplied the size of one backup by thirty and compared it against the size of the disk holding them, and by the time the gap surfaced, it wasn't backups that broke — it was the search index, silently unable to grow, on a machine that looked otherwise healthy.
By the end of part 2 the search engine had a corpus that could grow without filling a disk, on hardware that could hold it. That raised a different question. A broad crawl finds the same page under many URLs, mirrors and copies, thin and spammy pages, and whole sites in languages nobody will search for here.
My search engine has a small side feature: a gallery of people it has come across, grouped by what they're known for. Artists, musicians, politicians, journalists, and so on. On 2026-09-12 I noticed that the Artist bucket, a few entries away from Picasso, contained a well-known 20th-century dictator.