How to fix Container exited with status code 1 in Docker

DockerBEGINNERMEDIUMUpdated Dec 1, 2025· 253 views

Exit code 1 is a generic error indicating that a Docker container's process terminated due to an application error or misconfiguration. This catch-all error can stem from incorrect Dockerfile references, missing dependencies, or runtime exceptions within the containerized application.

Quick fix

Fixes 1

docker ps -a
docker logs <container-id>
  1. Check container logs for specific error messages
  2. Verify Dockerfile CMD and ENTRYPOINT paths
  3. Check entrypoint script permissions and shebang
  4. Verify all dependencies are installed
docker — error
docker ps -a
docker logs <container-id>
Container exited with status code 1

What this error means

Exit code 1 is Docker's generic error code indicating that a container stopped unexpectedly due to an application-level failure. Unlike more specific exit codes (such as 137 for OOM kills or 139 for segmentation faults), exit code 1 serves as a catch-all for various issues including programming errors, missing files, configuration problems, or failed initialization. When a container exits with code 1, it means the main process (defined by CMD or ENTRYPOINT) encountered an error and terminated with a non-zero exit status. This is often the result of the application itself returning exit(1) or throwing an unhandled exception, rather than a Docker daemon or kernel-level issue.

Typical symptoms

  • Container stops immediately after starting
  • Docker ps -a shows Exited (1) status
  • Application works locally but fails when containerized
  • Container restarts repeatedly in a crash loop
  • Error messages in docker logs pointing to missing files or permissions
  • CI/CD pipeline fails during container startup phase

Common causes

  1. Application error such as unhandled exceptions, division by zero, or runtime crashes
  2. Incorrect file paths in Dockerfile CMD, ENTRYPOINT, or COPY instructions referencing non-existent files
  3. Missing dependencies or libraries required by the application at runtime
  4. Incorrect permissions on entrypoint scripts or executables (not marked as executable)
  5. Invalid or missing shebang line in shell scripts (e.g., missing #!/bin/bash)
  6. Database connection failures or missing environment variables
  7. Configuration file syntax errors or missing required configuration
  8. Typos in command arguments or environment variables

How to fix "Container exited with status code 1"

1Check container logs for specific error messages

The first step is to examine what the application logged before exiting. Use docker logs to view stdout and stderr:

bash
docker ps -a
docker logs <container-id>

Look for error messages, stack traces, or warnings that indicate what failed. Common patterns include "No such file or directory", "Permission denied", "ModuleNotFoundError", or database connection errors.

2Verify Dockerfile CMD and ENTRYPOINT paths

Ensure that your Dockerfile's CMD and ENTRYPOINT directives point to files that actually exist in the container:

dockerfile
# Check that these paths are correct
CMD ["/app/start.sh"]
ENTRYPOINT ["python", "app.py"]

You can inspect the container filesystem to verify:

bash
docker run --rm -it <image> /bin/sh
ls -la /app/
3Check entrypoint script permissions and shebang

If using a shell script as your entrypoint, ensure it's executable and has a proper shebang line:

dockerfile
# In Dockerfile, make script executable
COPY start.sh /app/start.sh
RUN chmod +x /app/start.sh

Ensure your script starts with:

bash
#!/bin/bash
# or
#!/bin/sh

Note: Line endings matter. If you edited the script on Windows, convert CRLF to LF:

bash
dos2unix start.sh
4Verify all dependencies are installed

Check that all runtime dependencies are present in the container. For Python:

dockerfile
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

For Node.js:

dockerfile
COPY package*.json .
RUN npm ci --only=production

Use multi-stage builds to keep the final image clean while ensuring all build dependencies are available during compilation.

5Test the application locally before containerizing

Run your application outside of Docker to isolate whether the issue is container-specific:

bash
# For Python
python app.py

# For Node.js
node server.js

If it works locally but fails in Docker, the issue is likely related to:
- Missing files not copied into the image
- Different environment variables
- Path differences (/app vs relative paths)
- Missing system packages

6Check environment variables and configuration

Ensure all required environment variables are set and accessible:

bash
# Pass environment variables at runtime
docker run -e DATABASE_URL=postgres://... <image>

# Or use an env file
docker run --env-file .env <image>

In docker-compose.yml:

yaml
services:
  app:
    environment:
      - DATABASE_URL=${DATABASE_URL}
      - API_KEY=${API_KEY}
    # or
    env_file:
      - .env

Add debug logging to verify environment variables are loaded correctly.

7Inspect container state and recreate if needed

Sometimes container state becomes corrupted. Stop, remove, and recreate the container:

bash
# Stop and remove container
docker stop <container-id>
docker rm <container-id>

# Remove the image and rebuild
docker rmi <image>
docker build -t <image> .
docker run <image>

For docker-compose:

bash
docker-compose down
docker-compose up --build

Advanced notes

When debugging exit code 1 in production environments, consider implementing health checks and readiness probes to catch initialization failures early. In Kubernetes, use kubectl describe pod to view detailed event logs and exit codes. For recurring exit code 1 issues, implement structured logging with correlation IDs to trace the exact failure point. Consider using Docker's --init flag to properly handle signals and zombie processes, as improper signal handling can sometimes manifest as exit code 1. For CI/CD pipelines, temporarily add set -x to shell scripts or increase application log verbosity to capture more context about failures. Memory constraints can also cause applications to exit with code 1 before triggering an OOM kill (exit 137), so monitor container resource usage with docker stats.

Frequently asked questions

What does "1" mean?
Exit code 1 is Docker's generic error code indicating that a container stopped unexpectedly due to an application-level failure. Unlike more specific exit codes (such as 137 for OOM kills or 139 for segmentation faults), exit code 1 serves as a catch-all for various issues including programming errors, missing files, configuration problems, or failed initialization. When a container exits with code 1, it means the main process (defined by CMD or ENTRYPOINT) encountered an error and terminated with a non-zero exit status.
How do I fix "1"?
Exit code 1 is a generic error indicating that a Docker container's process terminated due to an application error or misconfiguration. This catch-all error can stem from incorrect Dockerfile references, missing dependencies, or runtime exceptions within the containerized application.
What causes "1"?
Application error such as unhandled exceptions, division by zero, or runtime crashes Incorrect file paths in Dockerfile CMD, ENTRYPOINT, or COPY instructions referencing non-existent files Missing dependencies or libraries required by the application at runtime
Is the "1" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading