Cómo ver los logs de un contenedor Docker

Docker captura la salida estándar y de errores de los procesos que se ejecutan en un contenedor. docker logs te permite consultar esa salida sin entrar al contenedor, lo que resulta imprescindible para diagnosticar fallos o simplemente entender qué está haciendo una aplicación.

Para seguir los ejemplos necesitas Docker instalado en tu sistema y un contenedor que genere salida, como Nginx.

Listar los contenedores

Antes de pedir logs, necesitas saber qué contenedores tienes y cómo se llaman.

docker ps

Esto muestra solo los contenedores en ejecución:

CONTAINER ID   IMAGE          COMMAND                  CREATED         STATUS         PORTS                  NAMES
a1b2c3d4e5f6   nginx:alpine   "/docker-entrypoint.…"   About a minute ago   Up About a minute   0.0.0.0:8080->80/tcp   web

Para ver también los contenedores detenidos (por ejemplo, uno que acaba de fallar):

docker ps -a

Anota la columna NAMES. Puedes usar el nombre o el ID para el resto de los comandos; el nombre es más legible.

Ver los logs de un contenedor

docker logs web

Esto imprime todo lo que el contenedor ha escrito en la salida estándar y en la de errores desde que se creó, en orden cronológico. Docker combina ambas salidas sin distinguirlas con colores.

Si el contenedor genera mucha salida y solo te interesa el final, puedes limitar el número de líneas:

docker logs --tail 50 web

--tail 50 muestra únicamente las últimas 50 líneas. Es lo primero que debe probar cualquiera que esté intentando entender un error reciente.

Seguir los logs en tiempo real

Para quedarte pegado a los logs mientras se generan (equivalente a tail -f en un archivo):

docker logs -f web

La opción -f (o --follow) mantiene el comando abierto mostrando las líneas nuevas a medida que aparecen. Es muy útil para ver en directo las peticiones que recibe un servidor web o un error que se repite.

Para salir del modo seguimiento, pulsa Ctrl+C en el terminal. Esto solo cierra docker logs; no detiene el contenedor, que sigue ejecutándose con normalidad.

Mostrar logs desde un momento concreto

Cuando el contenedor lleva horas funcionando, revisar todo el histórico es poco práctico. --since limita la salida a lo escrito a partir de un momento:

# Últimos 10 minutos
docker logs --since 10m web

# Desde una fecha y hora concretas (formato RFC 3339)
docker logs --since "2026-09-16T09:00:00Z" web

En el primer caso se usa una duración (10m, 1h30m); en el segundo, una marca de tiempo. La salida incluye desde ese instante hasta el final de los logs disponibles.

Añadir timestamps

Por defecto docker logs no muestra la hora en que se generó cada línea. Para incluirla:

docker logs --timestamps web

Existe también la forma abreviada -t. Los timestamps son especialmente útiles al diagnosticar problemas de rendimiento o intentar correlacionar dos líneas que parecen contradictorias.

Combinar opciones

Las opciones anteriores se pueden usar juntas. Un diagnóstico típico:

docker logs -f --tail 100 --timestamps web

Esto sigue los logs, empieza mostrando las últimas 100 líneas y añade la fecha y hora a cada una. No hay lógica oculta: cada flag aplica de forma independiente.

Contenedor ejecutándose frente a detenido

Los logs persisten después de que el contenedor se detenga. Si el proceso crasheó y quieres saber por qué, detén el contenedor y consulta sus logs:

docker ps -a
docker logs app-fallida

Esto funciona tanto si el contenedor está corriendo como si está detenido. La excepción es que el contenedor se haya eliminado con docker rm: en ese caso sus logs se pierden con él, porque Docker los guarda junto al contenedor. Si el contenedor se crea de nuevo (por ejemplo, con docker compose up), parte desde cero.

Para las políticas de reinicio automático y entender por qué un contenedor se ha reiniciado en bucle, en este blog puedes leer cómo reiniciar automáticamente contenedores Docker y así interpretar estos logs en contexto.

Errores frecuentes

No such container

Error response from daemon: No such container: web

El nombre o el ID no existe. Comprueba con docker ps -a que el nombre es exacto y que el contenedor no ha sido eliminado.

Los logs no muestran nada

A veces docker logs devuelve una salida vacía aunque la aplicación “funciona”. Las causas más comunes:

• La aplicación escribe en un archivo dentro del contenedor y no en la salida estándar, así que Docker no la captura. Suelen responder los archivos en /var/log/ de la aplicación.
• El contenedor se creó con un logging driver distinto del predeterminado. Docker asume json-file; si el contenedor usa otro driver (por ejemplo --log-driver syslog o journald), docker logs puede no mostrar nada o devolver un error. Puedes comprobarlo con docker info --format '{{.LoggingDriver}}' para el driver global, o con docker inspect del contenedor.

La salida es demasiado larga

Usa --tail para recortar y, si además quieres filtrar, combina con grep:

docker logs web 2>&1 | grep -i error | tail -20

Conclusión

Dominar docker logs es la base de cualquier tarea de mantenimiento: replica un error recurrente con -f, acota el problema con --tail y --since, y conserva la evidencia con --timestamps. Con estas cuatro opciones tienes resuelta la mayoría de los diagnósticos cotidianos de contenedores.