60-Second Linux Analysis - with Nix and LLMs

tl;dr: Analyze health of your server based on the famous 60-second Linux Performance Analysis but:

• One command to run it all
• Fast – do the 60 seconds analysis in around 6 seconds
• Just works – no sudo, no Docker, no installation of system-wide packages
• An optional AI summary at the end – no need to read walls of command outputs

You can build and run it from the source. For convenience, you can also run it with a single command (works on macOS too):

curl -fsSL https://gradient.engineer/60-second-linux.sh | sh

The 60-Second Rule for Linux Performance

In 2015, Brendan Gregg’s Netflix Tech Blog post introduced an excellent “60-second” playbook for quick Linux server diagnostics:

uptime             # System uptime, load averages
dmesg | tail       # Kernel ring buffer
vmstat 1           # Virtual memory statistics
mpstat -P ALL 1    # CPU utilization per core
pidstat 1          # Per-process CPU usage
iostat -xz 1       # Extended I/O statistics
free -m            # Memory usage
sar -n DEV 1       # Network device statistics
sar -n TCP,ETCP 1  # TCP counters and errors
top                # Top processes snapshot

This set of commands enables you to quickly identify CPU, memory, disk, and network bottlenecks and determine which areas require further investigation.

What’s the challenge?

Not every Linux distribution includes these tools by default – iostat and mpstat might be missing on minimal installations. During an outage, installing missing packages wastes precious time – especially when dealing with firewalls, immutable filesystems, outdated tool versions, or slow connections, as highlighted in Gregg’s more recent Linux Crisis Tools post.

We’re introducing open-source utility – gradient-engineer: it automatically downloads all necessary Linux tools to a temporary directory, executes the “60-second” playbook, and optionally summarizes results with an LLM. Our tool leverages Nix package manager to create a portable “toolbox” of Linux programs – without requiring root access, Docker, or permanent installations (everything is cleaned up when finished).

The command not found Nightmare

A common scenario: you connect to a remote server via SSH, want to perform basic troubleshooting, and immediately encounter:

$ iostat
bash: iostat: command not found

Every time I SSH to a newly created server, I’m frustrated that I can’t use my favorite tools (like ripgrep, htop, jq, tcpdump). It turns out LLMs can get frustrated too – here’s a snippet from Gemini 2.5 Flash reasoning while debugging a network problem:

The inability to run tcpdump and iftop cripples my real-time packet inspection.

As mentioned in Gregg’s Linux Crisis Tools post, installing tools mid-crisis can be problematic: timed-out package repositories, permission issues, or having only outdated tools in your distribution.

Our utility solves this problem by downloading tools on-demand without altering your system: a portable toolbox of necessary Linux utilities ready for the job.

Solution: A Portable Toolbox with Nix

Traditional Linux package managers (apt, yum) require root access, fail on distribution mismatches, and leave system clutter. Docker is heavy and requires root privileges. Manually compiling static builds is difficult for most software. We wanted something much more lightweight, in the spirit of modern package managers like npm, pip, or cargo.

So that is why we picked Nix.

Nix is a package manager that treats software and dependencies as pure code definitions, powered by its own functional language. Builds are reproducible and isolated. What’s particularly great for us is that Nix-built programs are independent of your Linux distribution and self-contained: they only use libraries/dependencies from other Nix packages, not from the system package manager. Moreover, Nix doesn’t rely on containers, virtual machines, or emulation – Nix-built programs are standard Linux executables.

In practice, this means you can copy the Nix root directory (/nix), move it to another computer, and run programs without issues. Since we copy the toolbox to a temporary directory rather than the /nix root directory, we use PRoot to redirect paths to the correct folder.

The Nix ecosystem includes nixpkgs – a vast repository of Nix-packaged programs (over 120,000 software packages), making it easy to extend our toolbox with additional tools in the future. It’s also straightforward to modify build instructions for programs defined in nixpkgs, allowing us to easily build custom versions of any packages.

AI-powered insights: From walls of text to actionable summary

Raw outputs from all “60-second” playbook commands are useful, but interpreting them can be challenging (what do us, sy, id, wa, st, avgqu-sz mean in command outputs?). Fortunately, this is where LLMs shine:

• Even less-powerful LLMs are great for summariztion tasks
• The full command output is included in the LLM prompt, reducing hallucination risk
• Since we use standard Linux tools, LLMs are familiar with their command-line interfaces and outputs
• LLM gives you a short overview, possible interpretations and next step suggestions - you’re still fully in control.

What’s even more powerful is that we can go beyond just running 10 commands sequentially: LLMs can analyze output from dozens of tools in seconds. With the “toolbox,” LLMs can easily use powerful troubleshooting tools.

Putting it to the test

We had a server with an overloaded disk. So, we run:

curl -fsSL https://gradient.engineer/60-second-linux.sh | sh

In just a few seconds, we received this report:

The system shows severe I/O bottleneck with CPU spending excessive time waiting for disk operations, primarily caused by a write-intensive process.

What’s Next?

This is an early prototype, and we’re just getting started. The repository is open-source at github.com/QuesmaOrg/gradient-engineer, and we’re excited to explore what’s possible.

Have a look at the current playbooks. We started with the classic, but we bet you have your own favorite commands—feel free to contribute them.

Another idea is to move beyond fixed playbooks to an agentic system, much like Claude Code. The real power here lies in giving LLMs access to the vast toolbox provided by Nix. An AI could install and use powerful tools like bpftrace on the fly, running sophisticated diagnostics within a secure sandbox. This would eliminate the command not found problem for AI agents, too.

We’re brainstorming many possibilities, but what’s your take? How do you currently diagnose your servers? Do you use LLMs to help with analysis, or do you prefer to avoid them altogether? Anc crucially - what’s the one tool you always miss on a bare-bones server?

We’d love to hear your thoughts! (Join the discussion on Hacker News, Reddit, etc.)