A container starts, stops and starts again

Symptom

The deployment’s restart count climbs. Logs show the application’s first few lines and then nothing, repeatedly. The status flickers between running and not.

Diagnose

1. Read the container’s own output first. The dashboard’s logs view, or odysseus logs <deployment>. An application that exits on a missing environment variable or an unreachable database says so, and no platform-side check will say it better.
2. Was it killed for memory? The container’s events carry the kill reason. A memory limit reached is a kill, not a crash, and the application’s log ends mid-sentence rather than with an error.
3. Is the health check killing it? A probe that fails repeatedly is treated as a failed container. Run the probe’s own command inside the image and see what it does — several images do not contain the tool a probe was written against.
4. Is the image the one you meant? A tag that moved under you produces a container that has never worked, which looks identical to one that broke.

Resolve

• Application error: fix it in the image, or supply what it is missing. A restart loop caused by configuration is fixed by the configuration, not by restarting.
• Memory kill: raise the limit, or reduce what the application holds. Changing the limit replaces the container, which is expected — the mutability column of the deployment reference says which fields do that.
• Probe failing: correct the command so the image can run it, or suppress an inherited probe deliberately. See health checks and process reaping.
• Wrong image: pin the tag. A tag that is not pinned is refused on create for this reason.

Prevent

Pin image tags, and write a probe that uses a tool the image actually carries. Both failures are cheap to prevent and expensive to diagnose under load, because the evidence scrolls past.