The 3am Page: orders-api Is Down
orders-api is down and a junior engineer has escalated it to you. There's no
runbook for this one - just what you learned across this course.
Nobody has told you what's wrong. Find out yourself:
systemctl status orders-api.service
sudo journalctl -u orders-api.service --no-pager
Read the actual error. It names the problem exactly.
Before you touch anything
Whatever the fix turns out to be, back up the service's files first:
mkdir -p ~/backups
tar -czf ~/backups/orders-api-backup.tar.gz -C /opt orders-api
Fix the actual cause
The journal told you exactly what failed. Fix it.
Bring it back up and prove it
Fixing the file isn't the same as the service being healthy. Start it, make sure it survives a reboot, and confirm - from its own logs, not just its status - that it's actually doing its job:
sudo systemctl start orders-api.service
sudo systemctl enable orders-api.service
sudo journalctl -u orders-api.service --no-pager
Hint 1
systemctl status shows the last few log lines inline, but
sudo journalctl -u orders-api.service --no-pager shows the full history - including
the very first failed start attempt, which is where the real error lives.
Hint 2
The unit file's ExecStart points straight at /opt/orders-api/run.sh. If
systemd cannot execute that file, the real cause is a plain file-permissions
problem, even though it's showing up as a systemd failure.