Reading Docker Logs on Your Phone: A Practical Guide
You can read Docker logs on your phone the same way you do on a laptop: SSH into the host and run docker logs. The docker logs mobile problem is really just screen size and typing, so the trick is knowing which flags trim the noise down to what fits on a 6-inch screen. A dedicated mobile app like Docker HQ skips the SSH typing entirely and streams logs with tap-to-filter, but the underlying commands are worth knowing either way.
The one command you actually need
Every container writes to stdout and stderr, and Docker captures both. To see them:
docker logs <container>
That dumps the whole history, which is the wrong move on a phone. You'll scroll forever. Add --tail to grab only the last N lines:
docker logs --tail 50 my-api
Fifty lines is about right for a phone screen. You get recent context without a wall of text. To follow new output as it arrives, add -f:
docker logs -f --tail 50 my-api
This is the combination I reach for most on mobile. It shows the last 50 lines, then live-tails anything new. Hit Ctrl-C to stop (on iOS SSH clients that's usually a dedicated Ctrl key in the keyboard accessory row).
Timestamps and time windows
Raw logs often lack timestamps, or the app's own timestamps drift from wall-clock time. Add Docker's:
docker logs -f --tail 50 --timestamps my-api
When you're debugging "it broke around 3am", narrow by time instead of line count:
docker logs --since 3h my-api
docker logs --since 2026-07-12T02:45:00 --until 2026-07-12T03:15:00 my-api
--since and --until accept both relative durations (10m, 3h, 2h30m) and absolute timestamps. On a phone, --since 10m is your friend. You almost never want the full history.
The docker logs mobile workflow over SSH
The part that hurts on mobile is typing ssh user@host and then a long docker logs line with a container name you half-remember. A few things make it bearable.
Define hosts in ~/.ssh/config so you connect with a short alias:
Host prod
HostName 203.0.113.10
User deploy
IdentityFile ~/.ssh/id_ed25519
Then it's just ssh prod. Most iOS and Android SSH clients (Termius, Blink, JuiceSSH) read this config or offer their own host list, so you tap a saved host instead of typing an IP.
You can also run the whole thing in one shot without an interactive shell:
ssh prod 'docker logs -f --tail 50 my-api'
That connects, streams, and drops you back when you Ctrl-C. Handy for a quick check from a saved snippet. Speaking of which, save your common log commands as snippets in your SSH client. Retyping docker logs -f --tail 50 --timestamps on a touch keyboard three times a day gets old fast.
If you're doing more than reading logs, the same SSH setup lets you restart containers, exec in, and check status. I wrote up the broader workflow in how to manage Docker containers from your phone.
Filtering logs on a small screen
The biggest mobile problem is signal-to-noise. You can't eyeball 500 lines the way you would on a monitor. Pipe through grep:
docker logs --tail 500 my-api 2>&1 | grep -i error
Note the 2>&1. Docker sends application errors to stderr, and grep only reads stdout by default, so without redirecting you'll miss exactly the lines you want. This bites people constantly.
To follow live and filter at the same time:
docker logs -f my-api 2>&1 | grep -iE 'error|warn|exception'
And to see a match plus a few lines of context around it, which matters when a stack trace spans multiple lines:
docker logs --tail 1000 my-api 2>&1 | grep -i -A 5 -B 2 'traceback'
-A 5 shows 5 lines after, -B 2 shows 2 before. On a phone this beats scrolling because you jump straight to the failure.
JSON logs
If your app logs structured JSON, grep still works but jq reads better:
docker logs --tail 200 my-api 2>&1 | jq -r 'select(.level=="error") | "\(.time) \(.msg)"'
That pulls only error entries and prints just the time and message, which is about all that fits on a phone anyway. If jq isn't installed on the host, plain grep '"level":"error"' gets you most of the way.
When docker logs comes up empty
Sometimes docker logs shows nothing and you assume the container is silent. Usually it isn't. Common causes:
- The app logs to a file inside the container, not stdout. Check with
docker exec my-api ls /var/log. If the app writes to/var/log/app.log,docker logsnever sees it. You'ddocker exec my-api tail -f /var/log/app.loginstead. The real fix is configuring the app to log to stdout, but that's a code change for another day. - A logging driver other than
json-fileorjournald. Rundocker inspect --format '{{.HostConfig.LogConfig.Type}}' my-api. If it sayssyslog,awslogs,gelf, ornone, thendocker logswon't work at all. That's expected behavior, not a bug. - Logs got rotated or the container was recreated.
docker logsonly has what's on disk for the current container. Adocker compose down && upstarts a fresh log.
If the driver is journald, you can still read logs on the host with journalctl:
journalctl CONTAINER_NAME=my-api -n 50 -f
That's the same tail-and-follow pattern, just through systemd.
Log size and rotation
Here's a caveat that matters more than it sounds: the default json-file driver has no log rotation unless you configure it. A chatty container can fill the disk and take the host down. On a phone you won't notice until you get a disk-full alert. Set limits in your compose file:
services:
api:
image: my-api:latest
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
That caps each container at 3 files of 10MB. To find the current culprit, check the log file sizes directly:
sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail
Doing this without the SSH gymnastics
Everything above works, and if you live in a terminal it's fine. But typing grep -iE on a touch keyboard while a container is crash-looping is genuinely miserable. This is where a purpose-built app earns its keep.
Docker HQ connects to your hosts over SSH and streams container logs with live tailing, so you tap a container and see output scroll in real time without typing a command. You can filter by keyword, jump to a time window, and switch between containers without reconnecting. Because it holds your host connections, checking logs across several servers is a couple of taps rather than several SSH sessions, which is the whole point when you're managing multiple Docker hosts from one screen.
The thing that actually saves you at 3am is the push alert. The moment a container dies or the host stops responding, you get a notification and open the app already knowing where to look, instead of finding out hours later. You can compare how the mobile options stack up in the best Docker mobile apps, and see plans on the pricing page.
Frequently asked questions
How do I see live Docker logs on my phone?
SSH into the host and run docker logs -f --tail 50 <container>. The -f follows new output in real time and --tail 50 limits the starting dump so it fits your screen. A mobile app such as Docker HQ streams the same live logs with a tap, no command typing.
Why does docker logs show nothing?
Most often the container logs to a file inside itself rather than stdout, or it uses a logging driver other than json-file/journald. Check the driver with docker inspect --format '{{.HostConfig.LogConfig.Type}}' <container>. If it's syslog, awslogs, or none, docker logs can't read it.
Can I search Docker logs from mobile?
Yes. Pipe through grep: docker logs --tail 500 <container> 2>&1 | grep -i error. The 2>&1 is important because errors go to stderr, which grep ignores by default. For structured JSON logs, jq filters more cleanly than grep.
How do I stop Docker logs from filling my phone's connection with noise?
Use --tail to cap the starting output and --since 10m to limit by time instead of dumping full history. Combine with grep to show only error or warning lines. On mobile you rarely want more than the last few dozen relevant lines.
Next step
Pick one production container and save docker logs -f --tail 50 --timestamps <name> as a snippet in your SSH client right now, before you need it. The next time something breaks while you're away from a laptop, you tap once instead of fighting a touch keyboard. And if you haven't set max-size on your logging driver yet, do that too. A full disk is a worse phone notification than any error line.