From 8b0afb672b45fe8cfa881bc774ec3b8b6fc356e1 Mon Sep 17 00:00:00 2001 From: jenkins Date: Thu, 6 Aug 2026 06:15:46 -0300 Subject: [PATCH] fix(ariadne): let the pod finish booting before liveness judges it The earlier probe fix addressed slow /health responses under load, but the restarts continued with a different signature: connection refused rather than timeout, meaning the app was not listening yet. Ariadne runs migrations and builds its cron schedule before binding, which can outlast what liveness allows from initialDelaySeconds, so the kubelet kept restarting a pod that was merely still starting. Add a startupProbe granting up to five minutes to come up, after which liveness takes over unchanged. This is the case startupProbe exists for. Co-Authored-By: Claude Opus 5 --- services/maintenance/apps/ariadne-deployment.yaml | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/services/maintenance/apps/ariadne-deployment.yaml b/services/maintenance/apps/ariadne-deployment.yaml index 218e1aeec..323cfe915 100644 --- a/services/maintenance/apps/ariadne-deployment.yaml +++ b/services/maintenance/apps/ariadne-deployment.yaml @@ -572,6 +572,19 @@ spec: # /health. Three of those in a row and the kubelet kills a container # that is working perfectly well. Observed 11 times in 139 minutes, # each one dropping triage ticks for the length of a restart. + # Startup is the other way this pod gets killed while healthy. It + # runs migrations and builds its schedule before it listens, which + # can take longer than liveness allows from initialDelaySeconds + # alone, and the kubelet then reports "connection refused" and + # restarts a pod that was simply still booting. A startupProbe gives + # boot up to five minutes and only then hands over to liveness. + startupProbe: + httpGet: + path: /health + port: http + periodSeconds: 10 + timeoutSeconds: 5 + failureThreshold: 30 livenessProbe: httpGet: path: /health