kubetail: tailing logs from multiple Kubernetes pods in one stream

The problem kubetail solves, and who it is for

A Kubernetes Deployment rarely has one pod. Run kubectl get pods and you get a list like app1-v1-aba8y, app1-v1-gc4st, app1-v1-m8acl, app1-v1-s20d0, app2-v31-9pbpn, app2-v31-q74wg. Each replica holds part of the story, and kubectl logs -f only follows one pod at a time. Reconstructing a request that bounced between replicas means opening several terminals and reading them side by side.

kubetail is a Bash script that aggregates the logs of several pods into a single stream. The README describes it as the same as running kubectl logs -f <pod>, but for multiple pods. That is the whole pitch, and it is a good one for anyone doing incident triage or local debugging from a shell: platform engineers, SREs, backend developers with kubectl access, and anyone who already lives in a terminal and does not want to open a browser tab for a quick look.

The matching is by pod name prefix. kubetail app2 follows every pod whose name starts with app2, which maps cleanly onto Deployment names. It is not a selector language over labels, and it is not a query engine. If you want to filter by label or by namespace across clusters, this is the wrong shape of tool.

How kubetail builds one stream from many pods

The repository is small: a single executable file named kubetail, a kubetail.plugin.zsh file for ZSH plugin managers, a completion directory with bash, zsh and fish scripts, a LICENSE, and a README. There is no daemon, no server, no config file and no state. The script resolves the pod list and then runs kubectl logs against each match, merging the output.

Because it shells out to kubectl, it inherits whatever cluster, context and credentials your kubectl is already using. There is no separate authentication path to configure and no agent to deploy. That also means the tool is exactly as fast and as reliable as the kubectl calls underneath it, and it stops working the moment your kubeconfig does.

Matching is done on names, with a regular expression mode when you need it. The README shows kubetail app1,app2 for two applications at once and kubetail "^app1|.*my-demo.*" --regex for pattern matching. Container selection is repeatable: kubetail app2 -c container1 -c container2 follows two named containers across the matched pods. Namespace selection exists but has an ordering rule the README calls out explicitly: pass the namespace flag after the container and application values, as in kubetail app2 -c container1 -n namespace1.

Installing kubetail and tailing your first pods

Homebrew is the shortest path on macOS and Linux, and it is the only installation route the README says gives you dynamic pod-name completion on kubetail <tab>. The tap has to be added before the formula-specific option is used, because Homebrew cannot recognise formula options before it has loaded the formula from the tap.

brew tap johanhaleby/kubetail
brew install johanhaleby/kubetail/kubetail

If you prefer the abbreviated kt command, the same formula takes a suffix flag. The README notes that after upgrading from the non-abbreviated installation on zsh you may need to run compinit for zsh to pick up the completion changes.

brew install johanhaleby/kubetail/kubetail --with-short-names

There is also a plain download route. The README says you can download the kubetail file directly, or any of the releases, and you are good to go. asdf users can add the plugin and install a version, and ZSH plugin managers such as Antigen, oh-my-zsh and zgen can load the repository as a plugin. Completion scripts for bash, zsh and fish are in the completion directory for people who did not install through Homebrew.

With the tool in place, list pods, then follow the group you care about. The README's example tails the two app2 pods in one stream:

kubectl get pods
kubetail app2

You should see interleaved lines from every pod whose name starts with app2, with each line prefixed so you can tell the sources apart. To follow one container across those pods, add -c. To follow two, repeat the flag.

kubetail app2 -c container1 -c container2

Color handling and the color-blindness escape hatch

When kubetail tails more than one pod it colorizes the output, and the -k argument controls how. The README documents three values: pod colorizes only the pod name and leaves the logged text in the terminal default color, line colorizes the entire line and is the default, and false disables color entirely. kubetail app2 -k false is the documented way to turn it off.

Colors that are hard to read can be skipped by index, either through the -z flag or the KUBETAIL_SKIP_COLORS environment variable, and either choice can be a comma-separated list. Finding the index is the awkward part, and the project addresses it directly: set -i true or KUBETAIL_SHOW_COLOR_INDEX=true and the index is printed as a prefix to the pod name, so a line reads like [3:my-pod-12341] some log. The README points out that this also helps people with color blindness, because the index is always printed in the terminal default color.

This is a thoughtful detail, and it is also a sign of the tool's scope. Color assignment, prefix formatting and index visibility are the extent of the presentation layer. There is no column layout, no timestamp normalization, and no way to save a view.

Where kubetail stops: no filtering, no highlighting, no persistence

The README is unusually blunt on this point: kubetail itself doesn't have filtering or highlighting capabilities built-in. The recommendation is to use iTerm2 on macOS for continuous highlighting of search terms, scrolling and multitab arrangements, and to use its timeline feature (cmd + shift + e) to display a timeline in your local timezone next to logs that are typically in UTC.

That answer works if you are on macOS with iTerm2. It does not help on Linux, in CI, or in a remote SSH session, and it means the quality of your log-reading experience depends on your terminal emulator rather than on the tool. Piping through grep is possible because the output is plain text on stdout, but you lose the per-pod prefix context that makes the merged stream readable in the first place, and the README does not document a supported way to keep it.

There is no daemon and no buffer, so nothing is retained. Close the terminal and the history is gone. There is no search across a time range, no structured parsing of JSON logs, and no way to share a session with a colleague. For a five-minute look at why a rollout is failing, none of that matters. For post-incident analysis, it is disqualifying, and you should be looking at a log backend instead.

kubetail vs stern, and the fork that adds multitail

The natural comparison is stern, which solves the same problem of following multiple pod logs in one stream. The difference in approach is in how pods are selected and how the tool is delivered. kubetail matches on pod name prefixes and regular expressions and ships as a single Bash script you can download and run, with no build step and no runtime dependency beyond bash and kubectl. stern is a compiled binary that selects pods through Kubernetes label selectors, which fits environments where labels are the source of truth and pod names are generated noise. If your team already reasons in labels, stern's model will feel more natural; if you think in Deployment names and want zero installation ceremony, kubetail's prefix matching is quicker to reach for.

The README also points to a fork by Alan Stebbens at aks/kubetail that allows richer configuration and uses multitail. That fork is the answer for people who want more than the upstream script offers without moving to a different selection model. The trade-off is that a fork is a separate project with its own maintenance and its own dependency on multitail, so you are no longer tracking one upstream release line. The README mentions the fork but does not describe its configuration format in detail, so evaluate it on its own repository.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-08, which is recent. Releases are tagged: 1.6.20 in February 2024, then 1.6.21 in October 2025 and 1.6.22 in November 2025. The gap between 1.6.20 and 1.6.21 is roughly twenty months, which is worth knowing if you were expecting a steady cadence. Version numbers are semantic-looking but the project is a script, so an upgrade is a file replacement rather than a dependency resolution exercise.

Upgrade cost is low by construction. Homebrew users run brew upgrade; everyone else re-downloads the script or the release. There is no config file to migrate, no database schema, and no API surface that can break. The realistic upgrade risk is in the surrounding tooling: the README warns that after upgrading from the non-abbreviated Homebrew installation you may need to run compinit for zsh to pick up completion changes, and the --with-short-names option depends on the tap being installed first.

The licence is Apache-2.0, a permissive licence that permits commercial use and modification and includes an explicit patent grant. That is a normal choice for a developer tool and imposes no obvious obligation on internal use. If you plan to redistribute a modified kubetail inside a product, read the LICENSE file in the repository yourself rather than relying on a summary; this article is not legal advice.

Editorial conclusion

Adopt kubetail if you debug Kubernetes workloads from a terminal and want one stream instead of several kubectl logs -f windows; install it from the Homebrew tap or the raw script and confirm your kubectl context and namespace first. Do not adopt it as a log aggregation or search layer, since the README states it has no filtering or highlighting built in. Before rolling it out to a team, verify that the -c container flags, the -n namespace flag placement, and the color-skipping flags behave as documented on your kubectl version.

Frequently asked questions

Official sources

1. Issues
2. johanhaleby/kubetail on GitHub
3. License: Apache-2.0
4. README
5. Releases