Docker Compose Failures That Kill an SDK Quickstart

Docker reports OOM as exit 137, which is 128 plus SIGKILL. A developer running your auth sample sees the login command fail and assumes your OAuth client is broken. They do not open a container inspector. They try another SDK.

Translate it. If auth-worker was killed, print a stable code, the container name, and the next step: raise the memory limit in the sample Compose file, or free Docker Desktop's cap. Keep the raw status too.

Port already allocated, daemon not running, a platform flag that pulled the wrong image, and a healthcheck that never passes. Each one needs its own code. A single 'failed to start stack' line makes every laptop look the same in your metrics.

Print the compose service name. 'auth-worker' is actionable. 'dependency failed' is not. If the fix is a one-line edit to the sample, print the line.

Scrollback disappears when they run compose down. The probe should already hold the code, the service, the exit status, and the question you asked. You can reproduce from that without a screenshare.

Do not upload the compose file if it contains registry tokens. The service name and the exit status are enough to see that the sample is too large for a default Docker Desktop VM.

If evaluators on 8 GB machines keep hitting the same OOM code, the sample is the bug. Cut a sidecar, lower a limit, or document a lighter path. Then the next developer does not pay for the first one's silence.

AethelLayer's own demo uses this shape: the login command, ERR_DOCKER_OOM, exit 137, then the question. That is the ticket you wish they had filed.