Problem with python slim base docker image in aws fargate

[lucas-wa]

I spent many days debugging a container that I deployed to AWS Fargate because the corresponding service in the cluster was marked as healthy, but the task was marked as unhealthy, even though the server was correctly responding to calls to the /healthy route. After changing the Docker image to use version 3.10.14 of Python instead of python-slim, the task was marked as healthy. My theory is that the base version might have limitations in threading, processing, or optimizations and was slow to respond to requests, but I didn't find anything that satisfactorily explains this.

[uldyssian-sh]

This is very unlikely to be an inherent “python-slim limitation” in threading or performance. What typically changes between python:<ver> and python:<ver>-slim is the set of OS packages and libraries available in the image.

On Fargate, the common pattern for “service looks healthy but task is unhealthy” with a working /healthy endpoint is that the container is failing the health check due to one of these differences:

The health check command or runtime dependencies are missing in slim images.

If your container or health check relies on tools like curl, wget, bash, CA certificates, or DNS utilities, -slim often does not include them by default.

If the health check is a CMD-style health check that runs a command inside the container (for example curl http://localhost:.../healthy), it can fail because curl is not present or because CA certs are missing.

Fix by either:

• switching the health check to an application-level HTTP check (ALB target group health check), or
• installing required packages in the Dockerfile:

Debian-based slim example:

RUN apt-get update && apt-get install -y --no-install-recommends
curl ca-certificates
&& rm -rf /var/lib/apt/lists/*

Timing is another frequent cause: default health check grace/timeout/retry settings can mark tasks unhealthy during slow startup, even if the endpoint works later.

Increase health check grace period / timeout / retries:

• ECS service health check grace period (especially behind an ALB)
• container health check interval, timeout, retries, and startPeriod

Also confirm the container is listening on 0.0.0.0 (not 127.0.0.1) and the correct port is exposed, because ALB health checks will fail if the server binds only to localhost.

The practical next step is to compare task logs and the ECS “Health status” details for the exact health check failure reason, and compare the installed OS packages between the two images.

Summary: python-slim is fine on Fargate, but it often omits packages (curl/CA certs/etc.) and exposes startup timing issues, which can make ECS health checks fail even though your app route works when you test it manually.

[uldyssian-sh]

Thanks! If this helps, please consider marking it as “Helpful” or “Accepted” 😊