When working with CI/CD pipelines or automated scripts, we often need to launch services in detached mode using docker-compose up -d. While this approach prevents shell dependency, it creates a blind spot - we lose immediate visibility into whether services actually started successfully.

Here are three reliable methods to check service status:

# 1. Check container status directly
docker-compose ps

# 2. View logs for specific service
docker-compose logs --tail=50 service_name

# 3. Inspect container health (if healthcheck configured)
docker inspect --format='{{json .State.Health}}' container_name

For CI/CD environments, consider this bash script that waits for services to become healthy:

#!/bin/bash
SERVICE_NAME="web"
TIMEOUT=120
INTERVAL=5

start_time=$(date +%s)
while true; do
    status=$(docker-compose ps -q $SERVICE_NAME | xargs docker inspect --format='{{.State.Status}}')
    
    if [ "$status" != "running" ]; then
        echo "Service $SERVICE_NAME failed to start"
        exit 1
    fi
    
    current_time=$(date +%s)
    elapsed=$((current_time - start_time))
    
    if [ $elapsed -gt $TIMEOUT ]; then
        echo "Timeout reached waiting for $SERVICE_NAME"
        exit 1
    fi
    
    sleep $INTERVAL
done

echo "$SERVICE_NAME is running successfully"

For more sophisticated monitoring:

# Check exit code of previous command in container
docker-compose exec -T service_name echo $?

# Verify network connectivity
docker-compose exec -T service_name curl -I http://dependent_service:port

# Verify application-specific health endpoints
docker-compose exec -T service_name curl -sS http://localhost:8080/health | grep '"status":"UP"'

Consider these patterns for different failure modes:

# Check for OOM (Out of Memory) kills
docker inspect --format='{{.State.OOMKilled}}' container_name

# Verify restart counts (indicates crashing containers)
docker inspect --format='{{.RestartCount}}' container_name

# Check for initialization timeouts
docker-compose logs service_name | grep -i "timeout"

For production environments, combine with tools like:

• Prometheus with cAdvisor
• Docker's built-in health checks
• Custom health check endpoints

When automating deployments through CI/CD pipelines, we frequently use docker-compose up -d to launch services in detached mode. While this prevents shell session dependency, it creates a blind spot - we lose immediate visibility into whether services actually started successfully or crashed immediately.

Here are the most effective ways to verify service status post-deployment:

# Basic container status
docker-compose ps

# Detailed container inspection
docker-compose ps --services
docker inspect $(docker-compose ps -q service_name)

# Filter by running state
docker-compose ps | grep -i "up"

For production-grade monitoring, implement Docker healthchecks in your compose file:

version: '3.8'
services:
  webapp:
    image: nginx:latest
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost"]
      interval: 30s
      timeout: 10s
      retries: 3

Then verify with:

docker-compose ps --filter health=healthy

For CI/CD pipelines, use this bash snippet to verify service availability:

#!/bin/bash
SERVICE_NAME="webapp"
TIMEOUT=120
INTERVAL=5

elapsed=0
while [ $elapsed -lt $TIMEOUT ]; do
  if [ "$(docker-compose ps -q $SERVICE_NAME)" ] && \
     [ "$(docker inspect -f '{{.State.Running}}' $(docker-compose ps -q $SERVICE_NAME))" = "true" ]; then
    echo "$SERVICE_NAME is running"
    exit 0
  fi
  sleep $INTERVAL
  elapsed=$((elapsed + INTERVAL))
done

echo "Timeout reached - $SERVICE_NAME failed to start"
exit 1

For programmatic access to container states:

# Using Docker SDK for Python
import docker

client = docker.from_env()
container = client.containers.get('your_container_name')
print(f"Status: {container.status}")
print(f"Health: {container.attrs['State']['Health']['Status']}")

• Not accounting for service dependencies in checks
• Assuming "running" state equals operational status
• Ignoring container exit codes (check with docker-compose ps --exit-code-from service_name)