AI Prompts Every Sysadmin Should Keep on Hand

This page may contain affiliate links.

If you look after servers, networks or a rack in a cupboard, you have probably already dabbled with ChatGPT, Claude or a local model. The problem is that most people use AI like a search engine: they ask a vague question, get a vague answer, and conclude it is overhyped. The sysadmins getting real value out of it are not cleverer than you. They just have a set of prompts they reuse, refined over time, that force the model to be specific, structured and useful.

Here are the ones worth keeping in a text file. Copy them, adapt the placeholders, and stop reinventing the wheel every time something catches fire at 4pm on a Friday.

1. The troubleshooting prompt that stops the guessing

The single biggest mistake is asking "why is my server slow?" with no context. The model fills the gap with generic advice about disk space and RAM. Instead, give it a role, the evidence, and a required output format:

"You are a senior Linux sysadmin. I have a Ubuntu 22.04 VM that is intermittently unresponsive. Evidence: load average 14 on 4 vCPU, iowait 38%, no swap usage. Output: (1) three most likely causes ranked by probability, (2) the exact command to confirm or rule out each one, (3) what the output would look like if that cause were correct. Do not suggest anything I cannot verify with a single command."

That last sentence is the important bit. It turns the model from a fortune teller into a checklist. You get iostat -x 1, iotop, dmesg | tail -50 and a clear idea of what you are looking for, rather than a lecture on best practice.

For network issues, swap the role and the evidence. Paste in your traceroute, ping and interface stats, and ask for ranked hypotheses with confirmation commands. The model is genuinely good at pattern-matching against symptoms it has seen a thousand times in training data.

2. The script-writing prompt (with guardrails)

Never ask for "a bash script to back up my files". You will get something that silently overwrites the wrong directory. Be explicit about safety:

"Write a bash script for Ubuntu that rotates daily backups of /var/www to /mnt/backup, keeping 7 days. Requirements: use set -euo pipefail, log to /var/log/backup.log with timestamps, check the destination is mounted before writing, never delete anything unless the new backup succeeded, and exit non-zero on any failure. Add comments explaining each section. Do not use rsync --delete."

Those constraints — set -euo pipefail, mount checks, no destructive flags — are the difference between a script you can run and a script that costs you a weekend. Always read what it produces. Always test in a VM first. The model writes confident code and confident code is not the same as correct code.

For PowerShell, same approach: state the OS version, the module you want to use, and whether it needs to run under a service account with no interactive session.

3. The documentation and runbook prompt

This is the one people overlook, and it is arguably where AI saves the most time. Nobody enjoys writing runbooks. Everybody needs them at 3am.

"Turn the following shell history and config snippets into a step-by-step runbook for rebuilding this service from scratch. Assume the reader is a competent sysadmin who has never seen this system. Include prerequisites, exact commands, expected output at each stage, and a rollback section. Use numbered steps and UK English."

Paste in your history, your Ansible playbook, your docker-compose file. What comes back is a first draft you can tidy in ten minutes rather than an afternoon. It will not be perfect, but a rough runbook beats no runbook every single time.

The same prompt works for handover documents, incident post-mortems and change requests. Feed it the raw material and let it do the formatting.

If you would rather not build and tune these prompts yourself, the Home Lab & Automation Pack is a ready-made set of AI prompts for scripting, troubleshooting and documenting your home lab, from £9. It is the done-for-you version of what this article teaches, if you would rather spend your evening actually running your lab than writing prompts for it.

4. The "explain this to me" prompt for unfamiliar tech

Sysadmins constantly inherit systems they did not build. A config file full of directives you half-remember, a Terraform module written by a contractor, a firewall ruleset nobody has touched in three years.

"Explain this configuration file line by line. For each directive, tell me what it does, what the default is, and what would break if I changed it. Flag anything that looks like a security risk or a deprecated option. Then summarise the whole file in three sentences."

This is genuinely transformative for inherited infrastructure. You get an annotated version of the file, plus a summary you can paste into your notes. Verify anything that sounds surprising against the official docs, but the model will usually point you at the right thing to check.

It is also excellent for error messages. Paste the full stack trace, not just the first line, and ask for the three most common causes in the wild.

5. The prompt for the boring 80%

A huge chunk of the job is not glamorous: writing regex, converting between formats, drafting emails to vendors, generating test data, translating a vendor's terrible documentation into something readable.

Keep a short prompt for each. For regex: "Write a regex that matches X and explain each part. Give me three test strings that should match and three that should not." For data: "Convert this CSV to JSON, preserving column order, and show me the first three records as validation." For vendor emails: "Rewrite this as a firm but professional escalation email. Keep it under 150 words. UK English."

None of these are impressive individually. Collectively they reclaim hours a week.

A few ground rules

Two things to keep in mind. First, never paste credentials, customer data, internal hostnames or anything covered by your employer's data policy into a public model. Use a local model via Ollama or similar if you need to work with sensitive material — the hardware to run a decent 7B or 13B model is affordable now, and a modest GPU or even a modern mini PC will handle it. If you are speccing a machine for local inference, it is worth checking current prices on components yourself, as they move constantly.

Second, treat every output as a draft from a confident junior who has never seen your environment. The prompts above are designed to make that draft verifiable. That is the whole trick.

Save these prompts somewhere you will actually find them. Tweak them as you learn what your model responds well to. The sysadmins getting ahead with AI are not the ones with the best model — they are the ones with the best prompts, reused relentlessly.