kubectl logs <pod> shows the current logs for a pod’s main container. Add -f to follow (live tail), --tail N for last N lines, --previous for the previous container instance, -c container for multi-container pods. The team that uses these flags for fast log access doesn’t need to deploy a sidecar just to read logs.
Table of contents
- Basic usage
- Tail last N lines
- Follow (-f)
- Multi-container pods
- Previous container instance
- All pods with label
- Timestamps
- Container runtime logs (not pod logs)
- Limit logs by time
- FAQ
Basic usage
kubectl logs my-podShows current logs. Errors if pod has multiple containers (need -c).
Tail last N lines
kubectl logs my-pod --tail=100Shows last 100 lines. The team that uses this avoids dumping megabytes of logs.
Follow (-f)
kubectl logs -f my-podLive tail. Like tail -f for the container. Ctrl-C to exit. The team that uses this watches logs during deployments.
Multi-container pods
Multi-container pods need -c:
kubectl logs my-pod -c sidecar-container
kubectl logs my-pod --all-containers=trueThe team that uses sidecar containers (e.g., log shippers) needs this.
Previous container instance
kubectl logs my-pod --previousShows logs from the previous instance (the one that crashed, was OOMKilled, etc.). The team that debugs crashes uses this.
All pods with label
kubectl logs -l app=myapp --tail=50Tail last 50 lines from all pods with the label. The team that uses label selectors has log aggregation without external tools.
Timestamps
kubectl logs my-pod --timestampsAdds RFC3339 timestamps to each line. The team that correlates with external events has timestamps.
Container runtime logs (not pod logs)
For container runtime logs (kubelet, containerd), use journalctl on the node:
sudo journalctl -u kubelet
sudo crictl logs <container-id>The team that debugs kubelet-level issues uses these.
Limit logs by time
kubectl logs my-pod --since=1h
kubectl logs my-pod --since-time=2026-07-05T10:00:00ZThe team that uses this gets recent logs without scrolling.
FAQ
How do I get logs from a previous pod instance?
kubectl logs my-pod --previous. The team that debugs crashes needs this - the current container might be healthy while the crashed one had the error.
Can I get logs from before the pod restarted?
No - logs are per-container. After container restart, the old logs are gone (unless logged to a persistent backend). The team that uses centralized logging (Loki, ELK) has historical logs.
How do I see logs from all pods of a Deployment?
kubectl logs -l app=myapp --tail=100. The team that uses label selectors gets logs from all replicas without naming each.
Why is kubectl logs returning nothing?
Either the container hasn’t logged yet, the log driver isn’t writing to stdout/stderr, or the pod was just created. The team that uses kubectl logs -f and waits has the answer.
Can I grep the logs?
kubectl logs my-pod | grep ERROR works for one-off. For live grep: kubectl logs -f my-pod | grep --line-buffered ERROR. The team that uses line-buffered grep has live filtering.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: