Claude/ChatGPT Prompt to Build a 60-Second Linux Performance Triage Runbook

What this prompt does

This prompt makes the model a senior SRE and asks for a precise, copy-ready first-60-seconds performance triage runbook. You set [server_role], the reported [symptom], [os_target], and a [time_window], and it returns the ordered command sequence (uptime, dmesg, vmstat, mpstat, pidstat, iostat, free, sar, top), what to look for in each given your symptom, a CPU/I/O/memory branch tree, five deeper commands, an incident-channel summary template, and an escalation note.

The structure works because a fixed triage order beats poking around when a server is just "slow" with no context. Running vmstat and iostat early answers the question everything else hangs off — CPU-bound or I/O-bound. [symptom] tells the model what to highlight in each command's output (saturation, queue depth, swap, steal time), [server_role] ties findings back to the workload, [time_window] scopes the historical sar inspection, and [os_target] keeps the tool flags right. The branch tree is the part that earns its keep: once the first nine commands have classified the bottleneck, it routes you to the right deeper tools instead of letting you wander, and the incident-summary template means you can communicate findings without breaking your investigation flow.

When to use it

• A server is "slow" with no context and you need a structured starting point.
• You want the Netflix-style first-60-seconds command order, not ad-hoc poking.
• You need to know exactly what to look for in each command's output.
• You want a branch tree that routes you to the right deeper tools by bottleneck class.
• You need a paste-ready summary line for the incident channel.
• You're triaging latency or load and want to settle CPU-vs-I/O fast.

Example output

Expect a numbered runbook: the ordered command sequence first, each command paired with what to look for given your [symptom], then a branch tree (CPU-bound do X, I/O-bound do Y, memory-bound do Z), the next five deeper commands like perf and strace once the bottleneck class is known, a one-line incident-summary template, and a cleanup/escalation note tied back to your server role.

Pro tips

• Set [symptom] specifically — "high latency under normal traffic" guides what the runbook tells you to watch far better than "it's slow."
• Run vmstat and iostat first as the runbook orders; CPU versus I/O is the fork everything else depends on.
• Use [server_role] so the escalation note and findings tie back to what the box actually does.
• Scope [time_window] realistically so the sar historical lookback matches when the problem occurred.
• Keep [os_target] accurate; some tools like sar and mpstat need the sysstat package and flags vary.
• Treat the branch tree as the decision point — commit to one class before running the deeper commands.
• Watch steal time in the CPU output if the box is a VM; a noisy neighbour can masquerade as your own application being slow.
• Paste the summary template into the incident channel early so others can follow along, even before you've reached a root cause.