Skip to content
Kituwa ITPrivate systems. Practical support.
Search Cart 0 Start a project
Menu

Kituwa IT · Field guide

Your server is down: what failed?

Start with the path, not the app. 1. Practical checks and official references.

Published

Start with the path, not the app.

This guide expands the Facebook post into a practical workflow for beginners, home-lab users, and small-business owners who want to understand the trade-offs before changing a working system.

What this guide covers

  • Your server is down: what failed?
  • Follow the path, not the panic.
  • 1 Power — Cable, PSU, UPS
  • 2 Network — IP, link, DNS
  • 3 Service — systemd, compose
  • 4 Logs — journal, container

Why it matters

The goal is not to memorize a product name or copy a command blindly. It is to understand what the change affects, verify it against an official reference, test it on spare hardware or a virtual machine when possible, and keep a rollback path.

A practical walkthrough

Check systemctl status

  1. Power: is the machine on? Check the power cable, PSU, and UPS.
  2. Network: can you reach the host by IP? Is the link up? Is DNS working?
  3. Service: is the process running? systemctl status and docker compose ps show state.
  4. Logs: journalctl -u <unit> or docker compose logs --tail=100 show the error.
  5. Dependencies: database, reverse proxy, storage, and certificates.
  6. Recent changes: updates, config edits, or a new deploy.

Make recovery practical

If you cannot reach the host at all, the problem may be power, link, or routing; if you can reach it but the app fails, move to service and logs. If you cannot reach the host at all, the problem may be power, link, or routing; if you can reach it but the app fails, move to service and logs. Fix one layer at a time and verify. Do not restart everything at once; you lose evidence. Document the last known good state. Test the recovery path. Keep a console path. Write down the failure path and the fix for next time. Document the last known good state. Test the recovery path. Keep a console path.

Verify the result

Test the change on a spare device or virtual machine first. Check the exact behavior you care about, not just whether the screen looks right. Record what you tested and what you expected.

Your turn

What was the last thing that changed?

What to verify

  • Use the official documentation for the exact version you run.
  • Test on a spare device or virtual machine before changing a working system.
  • Keep a backup and a rollback path.
  • Record what changed and how you verified it.

Common mistakes

  • Trusting a confident answer without a check.
  • Skipping a repeatable test set or factual review.
  • Sending private data to an endpoint you have not verified.

Quick checklist

  • ☐ Follow the path, not the panic.
  • ☐ 1 Power — Cable, PSU, UPS
  • ☐ 2 Network — IP, link, DNS
  • ☐ 3 Service — systemd, compose
  • ☐ 4 Logs — journal, container

FAQ

What is the first step?

Start with the path, not the app.

What should I avoid?

Trusting a confident answer without a check.

Where can I verify the current details?

Use the official references below; versions and interfaces change.

References

Need help?

If you want a second opinion on the setup or the rollback plan, Kituwa can review it with you. Start with the checklist above; it makes the conversation more useful.