No readiness probe
Part of Architecture & Best Practices, which counts for 15% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
A long-running workload defines no readinessProbe, so it receives traffic before it is ready and during restarts, causing avoidable request failures.
Why it matters
A long-running workload with no readinessProbe is sent traffic as soon as the container starts and throughout restarts and rollouts, before it can actually serve requests. Users see connection errors during every deploy and startup. A readiness probe gates traffic until the pod is genuinely ready. This is a heuristic scoped to long-running workloads.
How to fix it
Add a readinessProbe, usually an httpGet on a readiness endpoint that returns success only when the app can serve, including any warm-up or dependency checks it needs. Keep it separate from the liveness probe so a temporary dependency blip removes the pod from rotation instead of restarting it.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo