The script that drafts and schedules articles for this site starts a self-hosted LanguageTool server for each run, so every draft gets a grammar check before it's published. On 15 October, on the LFS laptop it now runs on, I found that LanguageTool hadn't started at all, and nothing in the script's output said so.
I wrote a piece in September about this site's average Google Search Console position falling from the 14-20 range to 7.8-9.4, right as a dozen new articles went live.
I run a small CRM for myself called CaRMen — a Symfony 7 API Platform backend with a React frontend. In August I had to bump api-platform/core from ^3.3 to ^4.0, not because I wanted the new major version, but because composer's own security-advisory audit flagged every 3.3.x and 3.4.x release in a row. There was no patched 3.x left to stay on.
My PHP projects don't run PHP on the host. This site runs in DDEV, CaRMen runs in a docker compose stack, and whatever PHP the host has is irrelevant to both.
This site runs Drupal's cron every 15 minutes from a crontab on the server, with the output appended to a log file in my home directory. For about twelve days in September, almost every one of those runs tried to send me an email, failed, and wrote two lines about it to that log. Nobody read the log. The emails were security update notifications.
A reindex that was scheduled purely as insurance, against a problem that almost certainly wasn't going to happen this time, finished with a real, measurable bonus nobody had gone looking for: nearly a third of the database's total index storage disappeared, cleanly, as a side effect of doing something that was never actually about storage in the first place.
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.