Real-world troubleshooting example

This example mirrors a common failure: the deployment does not become healthy, Diagnose runs automatically, and you learn that the container is not listening on the expected port (or that its memory limits are wrong).

Scenario: misconfigured port

You deploy a scope, but the rollout fails and Diagnose auto-runs. The Diagnose results show:

• ❌ Scope checks show a failure
• ✅ Service checks are successful
• ✅ Networking checks are successful

When you expand the failing Scope check, you see container_port_health failed. The check and logs say the application is not listening on port 8080 (the port configured in the deployment).

Step 1: Confirm the signal

In Diagnose, open container_port_health to review the explanation and logs. The log snippet points out the container is bound to a different port than the containerPort specified, so traffic cannot reach the app.

Step 2: Apply a fix

Update your deployment so the app listens on the configured port:

• Set the container to listen on 8080 (or update containerPort and probes to match the actual port).
• If probes are involved, verify readiness/liveness probes use the same port and path.

Save the change in your repo.

Step 3: Redeploy and verify

Redeploy the scope so the port change takes effect. After the new deployment is live, rerun Diagnose:

• container_port_health now passes
• Other checks complete successfully

Traffic flows and the rollout succeeds.

Another example: memory misconfiguration

If the failure is about memory instead of ports, Diagnose may surface memory_limits_check or a related check. Fix it by adding or correcting memory limits/requests in the deployment, redeploy the scope, and rerun Diagnose to confirm the issue is resolved.

Why this workflow works

• Diagnose pinpoints misconfigurations (ports, memory) without guesswork.
• You verify the fix on the redeployed scope, not on the failed rollout.
• You can rerun Diagnose anytime after redeploying to confirm the new state.