[Feature]: Record & Replay Mode (atop-style)

[Terry-Qin]

Is your feature request related to a problem?

I wish I could capture witr's process analysis over time and review it later. Currently witr only works in real-time, so if an interesting process appears and disappears (e.g. a short-lived cron job, a crashing service), there's no way to go back and see why it was running.

Describe the solution you'd like

A record/replay mode similar to atop:

• witr record -i <interval> -o <file> — periodically snapshot process information to a file
• witr replay -f <file> — restore and browse the recorded snapshots, ideally with the same query flags as live mode (--port, --pid, name, etc.)

The replay mode could support jumping to a specific timestamp and navigating forward/backward through snapshots interactively (TUI) or querying non-interactively for scripting.

Additional context

This is particularly useful for edge devices and servers where you can't always be watching in real time — you want to collect recordings continuously and analyze them after an incident. atop -w / atop -r is the direct inspiration.

[pranshuparmar]

@Terry-Qin Thanks for filing the request. What you’re asking for is a fairly large feature and drifts a bit from witr’s current design, so I want to get your use case right.

• Do you want to periodically snapshot a process’ witr output, store it, and inspect it later?
• Would a watch mode that refreshes and prints basic process details every few seconds fulfill your use case?
• If the TUI had an auto-refresh interval for the process detail view, would that solve what you’re looking for?

If what you want is periodic snapshots of the full output, you can already do that pretty easily today with a shell loop like:

while true; do witr --pid <pid> --json >> witr-record.jsonl; sleep 5; done

But adding record/replay as a feature into the product itself is a big commitment, so I want to be sure we're solving the right problem before making any decision.

[Terry-Qin]

@Terry-Qin Thanks for filing the request. What you’re asking for is a fairly large feature and drifts a bit from witr’s current design, so I want to get your use case right.

• Do you want to periodically snapshot a process’ witr output, store it, and inspect it later?
• Would a watch mode that refreshes and prints basic process details every few seconds fulfill your use case?
• If the TUI had an auto-refresh interval for the process detail view, would that solve what you’re looking for?

If what you want is periodic snapshots of the full output, you can already do that pretty easily today with a shell loop like:

while true; do witr --pid --json >> witr-record.jsonl; sleep 5; done
But adding record/replay as a feature into the product itself is a big commitment, so I want to be sure we're solving the right problem before making any decision.

Thanks for the detailed follow-up!

To answer your questions directly: yes, what I'm looking for is the first option — periodically snapshotting the full witr output and being able to inspect it later. The watch mode or TUI auto-refresh wouldn't cover my use case, since the goal is post-hoc analysis, not live monitoring.

The core scenario is: I want to run witr as a continuous background recorder during normal system operation, so that when something goes wrong, I can go back to the exact moment and reconstruct what processes were running, their ancestry, and their relationships — essentially "returning to the scene" after an incident.

The shell loop workaround works for a specific known PID, but in practice I often don't know which process will be interesting until after the fact, so I'd need to snapshot the full system state rather than track a single PID.

That said, I fully understand this is a significant architectural commitment. If the cost to the project is too high, feel free to deprioritize or close this — I just wanted to share the use case in case it's useful for your roadmap thinking.

[pranshuparmar]

@Terry-Qin Thanks for the quick clarification.

The scope is definitely bigger than I initially understood. What you’re describing is not periodic snapshots of a single process, but effectively periodic snapshots of the entire process graph of the system, which could easily mean hundreds or thousands of processes per interval.

The idea is genuinely interesting though. My initial instinct is that, if I were to build something like this, it would probably make more sense as a separate companion tool that consumes witr’s JSON output rather than baking it directly into witr itself.

That would give it room to evolve into a proper recording/analysis layer over time, with things like retention policies, indexing, querying, dashboards, timeline navigation, and so on, without pulling witr away from its current focus.

I’m going to keep this issue open for a while so that if anyone's interested, they can see and weigh in as well. This is definitely something that intrigues me, but the effort is going to be HUGE. Let me know if you have any more thoughts on this.

[ramanicsegnxt]

Zzfyt

[slaiyer]

Disclaimer: just came across this tool; I don't know its internals yet.

Instead of taking full snapshots at every interval, the recording format could be a time series of inferred deltas (binary/compressed?) in the state.
If the delta representation is larger than the snapshopt size itself, or if a certain amount of time has passed since the last snapshot, a new snapshot could be stored the way keyframes work in video encoding.
This would make time travel easier, and recording format relatively small.

[slaiyer]

Also, check sar out.