Less guessing.
Clearer next steps.

Build a useful baseline

Good documentation answers four questions: what does this system do, how do we know it works, what can we safely change, and how do we recover?

1. Define the service. Record its purpose, owner, supported users and expected behavior.
2. Describe dependencies. Identify power, storage, network, DNS and upstream services.
3. Capture a baseline. Note the OS version, service status, free space and normal response.
4. Write the rollback first. Keep the previous configuration and a specific restoration step.
5. Record the result. Include a timestamp, what changed and what was actually verified.

Examples on this page use reserved documentation names and addresses. Replace them only in your own private notes. Keep passwords, keys, personal information and private infrastructure details out of public documentation.

Networking essentials

Check each layer in order: local interface → route → DNS → port → application. One successful ping does not prove a website is working, and a blocked ping does not prove a host is down.

ip -brief address
ip route
getent ahosts example.com
curl -I --max-time 10 https://example.com/

Get-NetIPConfiguration
Resolve-DnsName example.com
Test-NetConnection example.com -Port 443

Interpret the symptom: a name-resolution failure suggests DNS; a connection timeout may indicate a path or filtering issue; a refused connection often means the address is reachable but nothing accepts that port. An HTTP error means the application responded—read its status and logs.

For diagrams and examples, use addresses such as 192.0.2.10 and names under example.com. These are documentation placeholders, not deployment targets.

Linux & Windows checks

Start with read-only observations. Capture the exact error and time before changing a service or restarting the machine.

cat /etc/os-release
uptime
df -h
free -h
systemctl --failed
systemctl status nginx --no-pager
journalctl -u nginx -n 40 --no-pager

Get-CimInstance Win32_OperatingSystem |
  Select-Object Caption, Version, LastBootUpTime
Get-Volume
Get-Service | Where-Object Status -eq 'Stopped'
Get-WinEvent -FilterHashtable @{
  LogName='System'; Level=2
} -MaxEvents 10

Backups you can restore

A successful backup job is useful evidence; a successful restore proves much more. Decide how much data loss is acceptable and how quickly the service needs to return.

• Scope: include application data, configuration and the instructions needed to rebuild.
• Separation: keep an independent copy outside the machine being protected. Consider offline or immutable storage for important data.
• Protection: restrict backup access and keep recovery keys available through a separate, secure custody process.
• Retention: keep enough history to recover from delayed discovery of corruption or accidental deletion.
• Restore drill: restore a small sample into a separate location, compare it and record the elapsed time.

A snapshot is a useful rollback point. When it shares the same storage and failure risks as the original, it should not be your only backup.

A repeatable troubleshooting loop

1. State the symptom: expected result, actual result, affected users and first known failure time.
2. Find the boundary: one device or all devices? Local access or public access? One URL or the entire service?
3. Check recent changes: deployments, updates, storage pressure, DNS and expiring certificates.
4. Form one hypothesis: choose the smallest observation that can support or reject it.
5. Change one thing: only after you have authorization and a rollback. Preserve the original error evidence.
6. Verify the user journey: test from the affected client's path, then record the result.

When an operation times out, its outcome may be unknown. Check the existing process, job record or receipt before resubmitting a change.

Small runbooks, clear outcomes

These are generic templates. Adapt the target, permissions and rollback to your environment before executing changes.