The Best AI Prompts for Linux System Administrators

The best AI prompts for Linux system administrators do four things every time: they hand the model an expert persona (“you are a senior Linux SRE”), they feed it your real specifics through fill-in placeholders instead of vague hand-waving, they ask for safety and back-out steps, and they demand a verification command so you can prove the fix worked. A prompt like “fix my server” gets you a confident, generic, sometimes dangerous answer. A prompt that says “here is the exact journalctl output, here is the distro and kernel, propose the least-destructive fix, give me the command to verify it, and tell me how to undo it” gets you something you can actually run on a production box at 2am. That difference — specificity plus guardrails — is the entire game.

I have spent enough on-call shifts pasting half-formed questions into a chat window to know what separates a prompt that saves the night from one that wastes it. This post is the curated set of prompts I actually keep in a scratch file, grouped by the situations where I reach for them, plus the cheat sheet for writing your own.

What makes a Linux admin prompt good (and what makes one dangerous)

Here is a weak prompt, the kind I used to type:

My server is slow, how do I fix it?

The model has nothing to work with. It will guess, and its guess will be a wall of generic advice — “check CPU, check memory, restart the service” — that you already know. Worse, if you ask it to “fix” something destructive without context, a less careful model may hand you a rm, a systemctl mask, or an iptables -F that locks you out of the box.

Now the strong rewrite:

You are a senior Linux SRE doing incident triage on a production
Ubuntu 22.04 host (kernel 5.15). Load average is 18 on an 8-core box
and climbing. Here is the top of `top` sorted by CPU:

[FILL IN: paste top output]

1. Tell me the single most likely cause given this data.
2. Give me read-only commands to confirm it before I change anything.
3. Only then propose the least-destructive fix.
4. Give me the exact command to verify the fix worked.
5. Tell me how to back out if it makes things worse.
Do not suggest a reboot unless you rule out everything else.

Same problem, completely different answer. The model now reasons from your data, leads with diagnosis instead of action, and — crucially — gives you a verification step and an escape hatch. Every prompt below follows that shape. Fill in the bracketed placeholders, paste your real output, and read the diagnosis before you run anything. The AI is a fast, knowledgeable colleague who has never seen your box; treat its output as a proposal, not a command to execute blindly.

For more on the tradeoffs between assistants for this kind of work, the comparison in ChatGPT vs Claude for infrastructure goes deeper than I will here.

Troubleshooting prompts

These are the ones I reach for when something is on fire and I need a second brain that does not panic.

Diagnose a high load average

When to use it: load is climbing, the box feels sluggish, and you need to know whether it is CPU, I/O wait, or runaway processes before you start killing things.

You are a senior Linux SRE. I have a high load average and need to
find the cause without making it worse.

Host: [FILL IN: distro + version, kernel, core count]
Symptom: load average is [FILL IN] on [FILL IN] cores.

Here is `uptime`, `vmstat 1 5`, and `top -b -n1 | head -20`:
[FILL IN: paste output]

1. Tell me whether this is CPU-bound, I/O-bound, or memory pressure,
   and how the numbers prove it.
2. Give me read-only follow-up commands to narrow it down further.
3. Propose the least-disruptive remediation.
4. Give me the verification command to confirm load is recovering.
5. Give me a back-out path if the remediation hurts.

Explain a systemd unit failure

When to use it: systemctl status shows failed, the journal is cryptic, and you want the failure decoded before you start editing unit files.

You are an expert in systemd. A unit failed to start and I need it
explained plainly.

Unit: [FILL IN: unit name]
Distro: [FILL IN]

Here is `systemctl status <unit>` and the last 40 lines of
`journalctl -u <unit> --no-pager`:
[FILL IN: paste output]

1. Explain in plain language why it failed.
2. Identify which directive or dependency is responsible.
3. Propose the minimal fix, showing the exact lines to change.
4. Give me the command to validate the unit file and restart it.
5. Tell me how to revert to the previous working state.

If you find yourself doing this a lot, the workflow in analyzing journald logs with journalctl and AI pairs well with this prompt.

Triage a full disk

When to use it: something wrote No space left on device and you need to find the offender and reclaim space without nuking something important.

You are a senior Linux sysadmin. A filesystem is full and I need to
reclaim space safely.

Mount point: [FILL IN]
Distro: [FILL IN]

Here is `df -h`, `df -i`, and `du -xhd1 /<path> | sort -h | tail -20`:
[FILL IN: paste output]

1. Tell me whether this is an inode or block-space problem.
2. Identify the largest reclaimable offenders from this data.
3. Rank cleanup actions from safest to riskiest, and flag anything
   that could break a running service.
4. Give me the command to verify space was reclaimed.
5. Warn me about any file I should NOT delete here.

The longer-form version of this lives in triaging disk space exhaustion on Linux.

Diagnose OOM kills

When to use it: a process vanished and dmesg mentions the OOM killer. You need to know who got killed, why, and how to stop it recurring.

You are a Linux memory and kernel expert. The OOM killer fired and I
need to understand it.

Host: [FILL IN: distro, kernel, total RAM, swap config]

Here is the relevant `dmesg -T | grep -i -A20 'killed process'` and
`free -h`:
[FILL IN: paste output]

1. Explain which process was killed and why the kernel chose it.
2. Tell me whether this is a leak, an undersized box, or a cgroup
   limit, citing the evidence.
3. Recommend a fix (limits, swap, tuning, or rightsizing) with the
   tradeoffs of each.
4. Give me a command to monitor for recurrence.
5. Note any change that would risk killing a different critical
   process instead.

Decode a confusing log line

When to use it: you have one error you do not recognize and you do not want a generic Google answer — you want it interpreted in the context of your stack.

You are an expert Linux administrator. Interpret this log entry for me.

Source: [FILL IN: which log / service]
Stack context: [FILL IN: what this host does]

Log line(s):
[FILL IN: paste]

1. Explain what this message actually means.
2. Tell me whether it is benign, a warning, or an active failure.
3. List the most likely causes, most probable first.
4. Give me one read-only command to confirm the top cause.
5. Do not propose any change until I confirm the cause.

Hardening and security prompts

The category where a bad prompt does the most damage, because “harden this” can quietly mean “lock yourself out.”

Harden sshd without locking myself out

When to use it: you are tightening SSH on a remote box you can only reach over SSH. The cardinal rule: never apply blind.

You are a Linux security engineer. Harden the SSH daemon on a remote
production server WITHOUT risking my ability to log back in.

Distro: [FILL IN]
Current `sshd_config` (relevant lines):
[FILL IN: paste]
How I authenticate today: [FILL IN: keys / password / MFA]

1. Propose a hardened sshd_config diff, explaining each change.
2. Flag any change that could lock me out and how to avoid it.
3. Give me the exact safe-apply procedure: keep my current session
   open, test with `sshd -t`, reload (not restart), and open a SECOND
   session to confirm before closing the first.
4. Give me the verification command to confirm the new config is live.
5. Give me the one-line rollback if the new session fails.

The full walkthrough is in hardening SSH on Linux servers.

Audit sudoers safely

When to use it: you inherited a sudoers file full of NOPASSWD and wildcards and you need to know what is actually dangerous.

You are a Linux privilege-escalation expert. Audit this sudoers
configuration for risk.

Here is the output of `sudo -l` for the user(s) in question and the
relevant lines of /etc/sudoers and /etc/sudoers.d/*:
[FILL IN: paste]

1. List every rule that grants more than it should, ranked by risk.
2. Call out specific escape risks (shell-outs, wildcards, NOPASSWD on
   editors or interpreters, ALL=(ALL)).
3. Propose least-privilege replacements for the worst offenders.
4. Remind me to edit only via `visudo` and give me the syntax-check
   command before I save.
5. Tell me how to undo a change that breaks legitimate access.

There is a deeper treatment in AI-assisted sudoers least-privilege audits.

Review a firewall change before it kills connectivity

When to use it: before you apply an nftables or iptables ruleset to a remote host, you want a second set of eyes that will catch the rule that drops your own SSH.

You are a Linux firewall expert. Review this ruleset before I apply it
to a REMOTE host I reach over SSH on port [FILL IN].

Tooling: [FILL IN: nftables / iptables]
Proposed ruleset:
[FILL IN: paste]

1. Trace whether my management SSH stays reachable after this applies.
2. Flag any rule ordering that would drop established connections.
3. Identify overly broad allows and anything redundant.
4. Give me a safe-apply plan with a timed auto-rollback (e.g. an
   `at` job that restores the old rules in 5 minutes unless I cancel).
5. Give me the verification command to confirm the rules loaded.

Pair this with AI-assisted firewall rule reviews for nftables.

Audit an inherited server

When to use it: day one on a box nobody documented. You want a structured first-pass inventory of what is running and what looks off.

You are a senior Linux administrator onboarding onto an undocumented
production server. Build me a read-only audit plan.

Distro/version: [FILL IN]

1. Give me a checklist of read-only commands to inventory: running
   services, listening ports, scheduled jobs, users with shells,
   sudo grants, recent package changes, and unusual SUID binaries.
2. For each command, tell me what a red flag in the output looks like.
3. Order the checklist so the highest-risk findings surface first.
4. Make every command non-destructive — nothing that changes state.
5. End with how to capture all of this into a single report file.

This mirrors the manual process in auditing an inherited Linux server.

Automation and scripting prompts

Where AI genuinely shines — drafting boilerplate you then review — provided you demand the safety properties up front.

Write an idempotent bash backup script

When to use it: you need a backup script you can run on a timer that is safe to re-run, fails loudly, and never silently corrupts a destination.

You are an expert bash author who writes production-grade,
idempotent scripts. Write a backup script.

Source path(s): [FILL IN]
Destination: [FILL IN: local path / rsync target / borg repo]
Retention: [FILL IN]
Runs via: [FILL IN: cron / systemd timer]

Requirements:
1. Start with `set -euo pipefail` and an explanation of why.
2. Be idempotent and safe to run twice in a row.
3. Quote every variable; handle paths with spaces.
4. Log to syslog/journal and exit non-zero on any failure.
5. Include a `--dry-run` mode that changes nothing.
6. After the script, give me the verification command to confirm a
   backup completed, and the command to test a restore.
Explain any line that could be destructive before showing it.

For the storage side of this, see Linux backup and restore with rsync and borg.

Review a cron job before production

When to use it: before you drop a new entry into a crontab, you want the schedule, environment, and failure behavior sanity-checked.

You are a Linux scheduling expert. Review this cron job before it
goes to production.

Crontab line(s):
[FILL IN: paste]
What it is supposed to do: [FILL IN]

1. Tell me exactly when this runs in plain English, and flag any
   schedule that overlaps or stampedes.
2. Check the environment assumptions (PATH, no shell expansion of %,
   absolute paths, locking against concurrent runs).
3. Identify what happens on failure and whether anyone gets notified.
4. Suggest whether a systemd timer would be safer here, and why.
5. Give me a command to test the job once, manually, before I trust
   the schedule.

If the answer leans toward timers, cron vs systemd timers covers the migration.

Convert a fragile one-liner into a maintainable script

When to use it: you have a pipeline of awk/sed/xargs that works but nobody, including you, can read it.

You are an expert in bash and text processing. I have a one-liner I
need turned into a readable, maintainable script.

The one-liner:
[FILL IN: paste]
What it does / should do: [FILL IN]

1. Explain step by step what the original actually does.
2. Rewrite it as a documented script with error handling and quoting.
3. Preserve exact behavior; call out any edge case the original
   mishandles.
4. Add a self-test or sample input/output I can run to confirm
   equivalence before I replace the original.

Performance prompts

For when the box is up but not happy.

Investigate slow disk I/O

When to use it: applications are stalling on writes and you suspect storage, but you want to confirm before blaming the disk.

You are a Linux performance engineer. Help me confirm or rule out a
disk I/O bottleneck.

Host: [FILL IN: distro, kernel, storage type]

Here is `iostat -xz 1 5` and `vmstat 1 5`:
[FILL IN: paste]

1. Tell me whether I/O is the bottleneck, citing await, %util, and
   wa from this data.
2. Identify the busiest device and likely the busiest process
   (suggest the command to confirm).
3. Recommend tuning or remediation with tradeoffs.
4. Give me the verification command to confirm improvement.
5. Note anything that would only mask the symptom.

The hands-on version is in diagnosing high load: CPU, memory, I/O on Linux.

Tune memory and swap behavior

When to use it: the box is swapping under load and you want to decide between more RAM, swap tuning, or zram.

You are a Linux memory-tuning expert. Advise on swap behavior under
load.

Host: [FILL IN: total RAM, current swap, swappiness, workload type]

Here is `free -h`, `cat /proc/sys/vm/swappiness`, and `vmstat 1 5`
during the problem:
[FILL IN: paste]

1. Tell me whether this swapping is harmful or normal for this
   workload.
2. Recommend whether to adjust swappiness, add zram, resize swap, or
   add RAM — with the reasoning for each.
3. Give me the exact commands, including how to make changes persist.
4. Give me the metric and command to verify the change helped.
5. Warn me about any change that could cause an OOM kill.

More depth in tuning Linux swap and zram for better memory performance.

Patching and maintenance prompts

The unglamorous work where AI is great at turning a vague worry into a concrete plan.

Plan a safe package upgrade

When to use it: before a round of apt/dnf updates on a production host, you want a change-managed plan, not a blind upgrade -y.

You are a Linux patch-management expert. Build me a safe upgrade plan.

Distro/version: [FILL IN]
Package manager: [FILL IN: apt / dnf]
Criticality of host: [FILL IN]

Here is the pending update list (`apt list --upgradable` or
`dnf check-update`):
[FILL IN: paste]

1. Flag any kernel, libc, or service-restarting packages that need a
   maintenance window or reboot.
2. Tell me which updates are security vs routine.
3. Give me the ordered, least-risk apply procedure, including a
   pre-change snapshot/backup step.
4. Give me the verification commands to confirm services came back.
5. Give me the rollback path (downgrade or snapshot restore) if an
   update breaks something.

The AI-assisted patch workflow is detailed in Linux package management: patching apt and dnf with AI.

Generate a maintenance-window runbook

When to use it: you have a scheduled change and want a step-by-step runbook with checks and rollback baked in.

You are an SRE who writes airtight runbooks. Draft a maintenance
runbook for the following change.

Change: [FILL IN: what you are doing]
Host(s): [FILL IN]
Window: [FILL IN]
Rollback time budget: [FILL IN]

1. Write numbered steps with a verification check after each one.
2. Include a pre-flight checklist (backups, notifications, health
   baseline) and an explicit go/no-go gate.
3. For every change step, include the exact back-out command.
4. Add a post-change validation section with the commands to confirm
   success.
5. Flag any step that is irreversible so I can plan around it.

The prompt-writing cheat sheet: 5 ingredients of a great ops prompt

Every prompt above is built from the same five parts. Learn these and you can write your own for any situation:

Persona. Open with the role you want the model to inhabit — “you are a senior Linux SRE,” “you are a Linux security engineer.” It anchors the tone, the assumptions, and the level of caution.
Specifics via placeholders. Distro, version, kernel, core count, and the actual output of a diagnostic command. [FILL IN: ...] placeholders force you to supply context instead of letting the model guess. Paste real data; that is where the leverage is.
Numbered asks. Break the request into ordered steps — diagnose first, then confirm, then remediate. Numbering stops the model from skipping straight to a fix and makes the answer easy to follow under pressure.
A verification command. Always end with “give me the command to confirm it worked.” A fix you cannot verify is a guess. This single line turns AI output from advice into something testable.
A back-out path. “Tell me how to undo this if it makes things worse.” On production, the rollback plan matters as much as the fix. Demanding it also nudges the model toward less destructive options in the first place.

Persona, specifics, numbered asks, verification, back-out. Five ingredients, every time.

Build your own library

You do not have to start from a blank scratch file. The free prompt library has copy-paste templates across DevOps and Linux ops, and you can adapt, save, and version your own in the prompt workspace so the prompt that saved you last quarter is one click away next time.

If you want a deeper, curated set built specifically for this work, the Linux Admin Prompt Pack is 100 battle-tested prompts covering troubleshooting, hardening, automation, performance, and patching — already structured with personas, placeholders, verification, and rollback baked in. It is the version of this scratch file I wish someone had handed me five years ago. And if you want the bigger picture of which assistants and helpers fit Linux work, browse the full Linux admins category.

FAQ

Which AI is best for Linux system administration?

There is no single winner — it depends on the task and how the answers fit your workflow. Both Claude and ChatGPT are strong at reasoning through Linux output, decoding logs, and drafting bash. In practice the bigger lever is your prompt: a well-structured prompt with persona, real output, and a demand for verification will outperform a sloppy prompt on any model. Try the same prompt on both and keep whichever gives you cleaner, more cautious commands for your stack.

Is it safe to paste server output into an AI?

Treat it like any external service: scrub secrets first. Redact passwords, private keys, API tokens, internal hostnames, and customer data before pasting. Log lines, top and vmstat output, and config files with credentials removed are generally fine. For sensitive environments, prefer an assistant with a clear data-handling and no-training policy, and when in doubt, anonymize hostnames and IPs. The diagnosis rarely depends on the literal secret.

Can AI write bash scripts I can trust?

It can write good first drafts — but you review every line before it runs on anything that matters. Ask for set -euo pipefail, quoted variables, idempotency, and a --dry-run mode, and demand the model explain any potentially destructive line. Then read it, test it in dry-run, and run it somewhere disposable before production. AI is a fast junior who never gets tired; you are still the senior signing off on the change.

How do I stop the AI from suggesting destructive commands?

Build the guardrails into the prompt. Tell it to lead with read-only diagnosis, to propose the least-destructive option, to flag anything irreversible, and to always include a back-out path. Adding “do not suggest a reboot or anything that drops connectivity unless you rule out everything else” steers it away from the nuclear options. The model follows the constraints you set — so set them.

Should I let AI run commands on my server directly?

Be cautious. Agentic tooling that executes commands can be useful for read-only diagnosis, but giving an AI write access to a production box is a real risk. The pattern in this post — AI proposes, you review and run — keeps a human in the loop where it counts. If you do wire up execution, scope it tightly: read-only by default, explicit confirmation for anything that changes state, and full audit logging.

Conclusion

The best AI prompts for Linux administrators are not clever incantations — they are disciplined ones. Give the model a persona, feed it your real output through placeholders, break the ask into numbered steps, and never close a prompt without demanding a verification command and a back-out path. Do that and AI stops being a slot machine of generic advice and becomes the calm, knowledgeable colleague you want on the other end of a 2am page. Save the prompts that work, adapt them to your stack, and keep them where you can reach them fast. The box does not care how good your memory is at 2am — but a good prompt library does the remembering for you.