Problem

billing-1 rebooted overnight for kernel patching. This morning the load balancer is throwing 502s for /payments and payments-api is down. The on-call before you started reading the application logs looking for a crash and was about to roll back last week's deploy.

Figure out WHY payments-api is down — is it actually a crash? — and name the correct fix before anyone rolls back or reinstalls a service that is perfectly fine.

Initial setup

• Host: billing-1, Debian 12 (systemd), freshly rebooted.
• Unit: payments-api.service, installed under /opt/payments-api.

Acceptance

You've solved it when:

• You've read systemctl status payments-api and seen it is `inactive

(dead) — stopped, not failed. There is no status=203/EXEC`, no crash, no signal. (systemctl is-failed agrees: it reports inactive.)

• You've read the journal (journalctl -u payments-api) and seen a clean

shutdown four days ago — Deactivated successfully, a graceful SIGTERM, no error — and nothing since. It was stopped during maintenance and never restarted.

• You've found WHY it didn't come back after the reboot: `systemctl

is-enabled payments-api says disabled` (the unit file even has a preset of enabled, so it should be on). A disabled unit does not start on boot.

• You've named the correct fix: systemctl start payments-api to bring it

up now, AND systemctl enable payments-api so it survives the next reboot — NOT a rollback, NOT a reinstall, and NOT a crash-hunt in the app logs.