witr: Process Provenance for SREs
During an incident, knowing that something is listening on a port is only half the job. You still need to know whether it came from systemd, a shell, a supervisor, a container runtime, or a developer script. witr answers that.
It is trending because it answers a question operators ask constantly. Instead of stitching together ps, ss, lsof, and systemctl by hand, witr traces the chain that caused the current state.
What Is witr?
witr is a cross-platform CLI and TUI for process provenance. It traces any process, port, container, or file back to the chain that started it.
That makes it different from normal host inspection tools. top shows activity, ss shows sockets, and docker ps shows containers. witr explains causality through text output, JSON, or an interactive dashboard.
For SREs, that is useful when a host looks wrong but the source is unclear. A surprise listener might be a stale service, sidecar, shell, or leftover deploy job. Find the starter chain first.
Key Features
- Traces processes, ports, containers, and files from one command
- Shows the responsible startup chain instead of only current state
- Provides CLI output for terminals and a TUI for interactive debugging
- Supports JSON output for automation, runbooks, and incident evidence
- Ships as a static binary with packages for Linux, macOS, Windows, and FreeBSD
Installation
The quickest Unix install path uses the project installer:
curl -fsSL https://raw.githubusercontent.com/pranshuparmar/witr/main/install.sh | bash
Package managers are also available:
brew install witr
sudo apt install witr
npm install -g @pranshuparmar/witr
go install github.com/pranshuparmar/witr/cmd/witr@latest
For fleets, prefer your normal package channel or a pinned GitHub release.
Incident Usage
Start with the thing that looks suspicious. If a port is open and nobody knows why, trace it:
witr :8080
If a process ID shows high CPU, start there:
witr 24391
For automation, capture JSON in an incident bundle:
witr --json :8080 > evidence/witr-8080.json
That output can sit next to logs, deploy metadata, service status, and container inspection. It preserves the reasoning chain for handoffs.
Operational Tips
Add witr to host triage runbooks, but keep it scoped as an investigation tool. It identifies ownership and startup paths, then your normal controls should handle remediation.
Use it before killing unfamiliar processes. A process tree can reveal that the real owner is a supervisor, scheduled job, or container runtime. Killing the child may only restart it.
For AI-assisted incident response, witr JSON is useful context. An agent can combine provenance with alert labels, deploys, and logs before recommending action.
Conclusion
witr is a small tool with a practical SRE payoff: it makes runtime causality visible. When a host has an unexpected process, listener, container, or file, that can save minutes when every assumption is expensive.
Akmatori helps SRE teams connect alerts, metrics, logs, traces, and runbooks into governed incident workflows. Powered by Gcore, Akmatori gives operators the control they need when production behavior needs a fast explanation.