- Ya
- 4 Septemba 2026, 20:41 UTC
- Mwandishi
- Kamo
- Ahadi ya
- cf1e405
Every fix in this programme is a claim about what happens during a rollout. Until now those claims were untested: MediaService shipped with strategy Recreate at one replica for its entire life, so every deploy deleted the only pod serving chat and attachments and started the replacement afterwards — a ~65 second hole, several times a day — and nothing measured it. The first anyone knew was a member reporting a failed document upload, and even that read as a flaky feature rather than as chat being down on a schedule. A blackbox exporter now loads the eight public hosts every 10 seconds. Ten, not the 30s default: the failure this exists to catch is short by design, and at 30s a clean graph would only mean the hole fell between two scrapes. Two alerts matter, and the second is the more useful: PublicHostDown a host has not answered for a minute. An outage, deploy or not. PublicHostFlapping below 100% success over ten minutes. This is the one that catches a rollout dropping a handful of requests — it recovers long before a 1m 'for' elapses, which is precisely why that failure gets reported as 'it randomly logged me out' and never as an incident. Plus a certificate alert (the cold-Traefik self-signed failure had no detector at all), a stuck rollout alert, and one for a Deployment sitting below its desired replica count — because replicas: 2 only helps while the second pod is actually up, and one that is not looks healthy. TLS verification is deliberately on: a certificate this platform serves wrongly must fail the probe, since that is exactly what a cold Traefik used to do to every org at once. monitoring/ is not a CI apply target by long-standing convention here, so both files carry their own apply line.