Save Terminal Commands: A Guide for SREs

As an SRE, you run commands that matter. Restarting services, scaling infrastructure, debugging production—these aren’t commands you want to improvise at 3am.

Yet most teams save terminal commands haphazardly: Slack threads, personal notes, outdated wikis. Here’s how to do it properly.

Why SREs Need to Save Terminal Commands

Incident Response

During an incident, speed matters. If you have to construct commands from scratch, you’re losing precious minutes. Saved, tested commands let you act immediately.

Knowledge Transfer

When you save terminal commands properly, you’re documenting operational knowledge. New team members can execute procedures without shadowing you for weeks.

Audit and Compliance

Many environments require audit trails. “I ran a command from memory” doesn’t satisfy auditors. Documented, version-controlled commands do.

How SREs Should Save Terminal Commands

Organize by Service

Don’t dump all commands in one file. Organize by what they operate on:

runbooks/
├── api/
│   ├── restart.md
│   ├── scale.md
│   └── debug-latency.md
├── database/
│   ├── failover.md
│   ├── backup.md
│   └── restore.md
└── kubernetes/
    ├── drain-node.md
    └── cordon-node.md

Include Pre and Post Conditions

A command without context is dangerous. Save terminal commands with their requirements:

# Scale API Service

## Prerequisites
- [ ] Confirm current load warrants scaling
- [ ] Check cluster has capacity: `kubectl top nodes`
- [ ] Verify HPA is not fighting you: `kubectl get hpa api -n prod`

## Scale Up

​```bash
kubectl scale deployment/api -n prod --replicas=10
​```

## Verification
- [ ] Watch rollout: `kubectl rollout status deployment/api -n prod`
- [ ] Check new pods are healthy: `kubectl get pods -n prod -l app=api`
- [ ] Verify latency dropping in dashboard

Parameterize Dangerous Commands

Never save terminal commands with hardcoded production values for destructive operations:

# Delete Stuck Pods

⚠️ **Warning**: This forcefully terminates pods

​```bash
# Replace NAMESPACE and POD_NAME before running
kubectl delete pod POD_NAME -n NAMESPACE --force --grace-period=0
​```

Use this only when: Pod is stuck in Terminating state for >10 minutes

Add Rollback Procedures

Every change command should have an undo:

# Enable Feature Flag

## Enable

​```bash
curl -X POST https://api.internal/flags/new-checkout \
  -H "Authorization: Bearer $API_TOKEN" \
  -d '{"enabled": true}'
​```

## Rollback

If issues arise, disable immediately:

​```bash
curl -X POST https://api.internal/flags/new-checkout \
  -H "Authorization: Bearer $API_TOKEN" \
  -d '{"enabled": false}'
​```

Version Control Is Non-Negotiable

When you save terminal commands in Git, you get:

Change History

git log --oneline runbooks/database/failover.md
# Shows every change to the failover procedure

Blame

git blame runbooks/api/restart.md
# Who added this step? When? Why?

Code Review

Runbook changes should go through PR review just like code. A bad command in production is worse than a bug.

Rollback

git checkout HEAD~1 -- runbooks/api/restart.md
# Revert to previous version

From Saved to Executable

Saving terminal commands is necessary but not sufficient. The real power comes when those saved commands become executable.

Static documentation has problems:

• Commands go stale without anyone noticing
• Copy-paste introduces errors
• There’s no execution log

Executable runbooks solve these:

• Running the command proves it works
• No copy-paste needed
• Every execution is logged

Making Saved Commands Executable

The leap from “documented” to “executable” requires tooling. You need something that:

1. Reads your Markdown files
2. Lets you execute code blocks step-by-step
3. Shows output inline
4. Handles SSH connections
5. Stores in Git

That’s what Stew does. Take your saved terminal commands, open them in Stew, and execute them reliably.

Join the waitlist to turn your command library into executable runbooks.