witr is an open-source, Apache-2.0 licensed Go tool with both a command-line interface and an interactive terminal UI that traces any process, port, container, or file back to the exact chain of systems that started it, and it is built for operators, SREs, and developers who need to answer "why is this running?" during debugging and incident response.

What it is

witr exists to answer one question: why is this running? Whenever something is running on a system — a process, a service, or anything bound to a port — there is always a cause, and that cause is often indirect, non-obvious, or spread across multiple layers such as supervisors, containers, services, or shells. The project is a single static binary written in Go that reports where a running thing came from, how it was started, and which chain of systems is responsible for it existing right now, delivered as human-readable output, machine-readable JSON, or an interactive TUI dashboard. It sits in the Infrastructure & Operations / Monitoring & Observability category and is distributed under the Apache-2.0 licence, with packaging maintained independently across a wide range of operating system ecosystems.

The concrete problem it solves is manual correlation. Existing tools — ps, top, lsof, ss, systemctl, and docker ps — expose state and metadata. They show what is running, but they leave the user to infer why by comparing output from one tool against output from another. witr makes that causality explicit in a single place, so the answer to why a port is held or a container is alive does not require three terminals and a mental join across supervisor, container runtime, and service manager layers.

Key capabilities

• Traces processes, ports, containers, and files back to the exact starting chain rather than reporting state alone.
• Offers three consumption modes from one tool: human-readable terminal output, machine-readable JSON, and an interactive TUI dashboard.
• Ships as a single static binary covering Linux, macOS, Windows, and FreeBSD.
• Provides a browser sandbox with a guided tutorial and free-play environment that investigates a simulated Linux box, requiring no install.
• Documents an explicit flags and options reference plus a core concept section describing how traces are assembled.
• Installs a man page as witr.1 alongside the binary for offline reference.
• Is packaged across many ecosystems, including brew, conda, aur, winget, npm, and ports.

Who uses it and how

• Incident responders use it on live hosts to reconstruct why an unexpected process or port binding exists before making changes.
• DevOps and platform engineers use it across Docker and Kubernetes environments where the responsible layer is a supervisor, a container runtime, or a service manager rather than a login shell.
• Operators on Linux, macOS, FreeBSD, and Windows use the platform-specific install paths for their environment.
• Developers use it on their own machines to explain stray processes and listening sockets without assembling a picture from several utilities.
• Tooling authors consume the JSON output to feed trace data into other automation.

Getting started

On Linux, macOS, and FreeBSD the quickest route is the install script, invoked as curl -fsSL https://raw.githubusercontent.com/pranshuparmar/witr/main/install.sh | bash, which detects the OS and CPU architecture, downloads the latest released binary and man page, installs the binary to /usr/local/bin/witr, and honours INSTALL_PREFIX to override the path. On Windows, irm https://raw.githubusercontent.com/pranshuparmar/witr/main/install.ps1 | iex downloads and checksum-verifies the release, extracts witr.exe to %LocalAppData%\witr\bin, and adds that directory to the user PATH; apt install witr and other package managers are also available.

How it compares

The tools witr positions itself beside are ps, top, lsof, ss, systemctl, and docker ps, all of which expose state and metadata for a single layer and leave the user to infer cause. witr does not replace their state reporting; it adds the causal explanation across supervisors, containers, services, and shells that those tools individually cannot produce.

When to use it — and when not to

witr is a single static binary, so there is no database, object storage, or SMTP service to operate; the install script only needs write access to /usr/local/bin and the man page directory, which INSTALL_PREFIX can redirect. Community packages may lag GitHub releases because they go through independent review and validation, so anyone who needs the newest behaviour should prefer the install script over a distribution package. It is the wrong pick for environments where the responsible party cannot be inspected at the process-tree level, since a trace depends on visibility into the layers that actually launched the thing.

curl -fsSL https://raw.githubusercontent.com/pranshuparmar/witr/main/install.sh | bash

irm https://raw.githubusercontent.com/pranshuparmar/witr/main/install.ps1 | iex

sudo apt install witr

brew install witr

sudo port install witr

conda install -c conda-forge witr
# alternatively using mamba
mamba install -c conda-forge witr
# alternatively using pixi
pixi global install witr

yay -S witr-bin
# alternatively using paru
paru -S witr-bin
# or use your preferred AUR helper

winget install -e --id PranshuParmar.witr

npm install -g @pranshuparmar/witr

pkg install witr
# or
pkg install sysutils/witr

cd /usr/ports/sysutils/witr/
make install clean

choco install witr