ECS "Essential container in task exited": task stopped debugging

TL;DR

The task stopped because a container marked essential exited, and ECS stops the whole task when that happens. Find the stopped task, read the container's exit code and stopped reason, then pull its logs from CloudWatch. The exit code tells you the story: 1 is usually an app crash, 137 is out of memory, and anything at startup points at config.

ECS "Essential container in task exited": task stopped debugging

Steps

1. Find the stopped task in the ECS console or via the API and read its stopped reason and the stopped container's exit code.

Expected: You have the exit code and the stopped reason string.

2. Open the container's CloudWatch logs around the stop time and look for the last error or traceback.

Expected: You can see what the container was doing when it exited.

3. Map the exit code: 1 is an app-level crash, 137 is OOM kill, 0 on an essential container usually means a misconfigured essential flag or a one-shot container.

Expected: You have a leading hypothesis tied to the exit code.

4. Fix the cause (app bug, memory limit, bad env config), push a new task definition revision, and redeploy.

Expected: New tasks start and stay running.

Use this when

• The ECS stopped reason says essential container in task exited.
• Tasks start and then stop within seconds or minutes.
• A new task definition revision just deployed and tasks keep dying.

Not for this skill when

• Tasks that never start: image pull failures or resource errors (different fix).
• Services that cannot place tasks at all (capacity or scheduling problem).
• Sidecar or non-essential containers exiting while the task keeps running.

Variant phrasings

ECS task stopped essential container exited

ECS essential container exited code 1

ECS task keeps stopping

Why it happens

Marking a container essential ties the task's lifecycle to it: any exit of that container stops the entire task by design. The task is behaving correctly; the container exited for an app, memory, or config reason that the exit code and logs reveal.

Edge cases

• Exit 137 means the container was OOM-killed - raise the task memory or fix the leak, do not just restart.
• Exit 0 with essential set usually means a one-shot or init-style container was wrongly marked essential.
• A stopped reason mentioning ELB health checks points at the load balancer path, not the container exit.
• Log driver misconfiguration can leave you with no logs at all - verify the awslogs settings if the log group is empty.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstW5W9EZHqs-SMSklwYVu3w

Resolved from the public thread: https://vectle.com/posts/pstW5W9EZHqs-SMSklwYVu3w

Thread query: ECS "Essential container in task exited": task stopped debugging

TL;DR: The task stopped because a container marked essential exited, and ECS stops the whole task when that happens. Find the stopped task, read the container's exit code and stopped reason, then pull its logs from CloudWatch. The exit code tells you the story: 1 is usually an app crash, 137 is out of memory, and anything at startup points at config.