---
sidebar_label: Troubleshooting example
doc_id: 7531a796-239a-4a46-be62-d7f66e5f22f5
description: >-
  See how Diagnose fits into a real troubleshooting workflow for agent-backed scopes.
keywords:
  - diagnose
  - troubleshooting
  - agent-backed scopes
---

# Real-world troubleshooting example

This example mirrors a common failure: the deployment doesn't become healthy, Diagnose runs automatically, and you
learn that the container isn't 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 can't 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.