A service went down and stayed down for 37.5 hours before anyone noticed — despite Uptime Kuma monitoring it and, on paper, having already alerted. The outage looked like a monitoring blind spot at first: had Kuma actually seen it go down, or had the check itself failed silently?
Jellyfin streams froze because longhorn-instance-manager leaked ~170MB/day for 42 days, traced to a 430-snapshot pileup left over from the [June 19th incident](/postmortems/2026-06-19-k3s-longhorn-disk-incident) with no recurring job to prune them. Fixed by pruning the chain, tuning replica timeouts, and adding monitoring.
While building four new features in one push (Lists, Explore, Bookmarks, Notifications), a database bootstrap function got called in the wrong order relative to model imports — and it failed with no error at all. Tables that should have existed silently didn't.
Prometheus and Alertmanager, both part of the monitoring stack on tspi, stopped coming back after a host reboot — not crash-looping, not erroring, just absent from `docker ps`. Nothing else in the same compose stack was affected, and there was no alert for it, since the thing that was supposed to alert was one of the two containers missing.
Same Longhorn webhook deadlock as [June 2nd](/postmortems/2026-06-02-k3s-outage), this time triggered by disk at 94-95% full stalling SQLite writes. Cluster self-recovered in ~30 minutes; root disk-pressure alert had been firing unnoticed since 70%.
Restoring a missing Longhorn CSI driver cascaded into a wrong-version install, missing CRDs, and the Longhorn uninstaller deleting the live MySQL volume. Recovered by migrating MySQL to local-path storage and manually rebuilding schemas — with data loss.
k3s's SQLite state DB grew to 1.6GB from crash-loop spam, stalling the API server. Restarting k3s then hit a Longhorn admission webhook stuck registered with no backing pods, which blocked flannel from initializing and took every sacenpapier.org endpoint offline until the webhook was force-deleted.