Separate Docker launch errors from the application’s exit status

A failed docker run command does not always mean the application started and crashed.

Source facts

Docker documents distinct docker run exit meanings: 125 indicates a Docker-side invocation or daemon error, 126 means the specified command could not be invoked, and 127 means it could not be found. Other exit statuses reflect the command run in the container. The distinction helps locate failure before interpreting application logs.

Source: Docker documentation — Running containers.

Applicability

Review docker run’s documented launch-error categories before interpreting the contained command’s result.

DSE recommendation

DSE recommends capturing the exact invocation, sanitized error output, image reference, and exit status when a launch fails. Determine whether Docker accepted the request and whether the intended executable was available before investigating application initialization. Keep command-path, executable-permission, and daemon-connectivity problems separate. Do not publish credentials contained in command arguments when collecting evidence. If a wrapper script translates exit codes, record that behavior so an automation system does not misclassify a launch failure as a completed application task.

Verification

Using a disposable image, compare a harmless valid command, a missing executable, and a deliberately invalid Docker option. Observe the status and error location for each. Confirm the operational wrapper preserves enough information to route launch failures separately from application failures. Retain the wrapper’s reported status beside Docker’s original status for each case. Ask the automation owner to demonstrate the correct alert or failed-task classification without relying on a generic error label.

Official reference

Docker documentation — Running containers. Reviewed October 20, 2026.