A reboot is rarely the problem. What breaks is the thing somebody started by hand during an incident and never enabled, so it comes back only as long as nobody restarts the machine. Find those before you need to reboot, not after.

Before: what is running that is not enabled

systemctl list-units --type=service --state=running --no-pager \
  | awk '{print $1}' | grep '\.service$' \
  | xargs -I{} sh -c 'systemctl is-enabled {} >/dev/null 2>&1 || echo "NOT ENABLED: {}"'

Anything printed will not come back. Enable it now: sudo systemctl enable name.

Also check

  • Mounts made by hand - findmnt against /etc/fstab. See adding a second disk.
  • Firewall rules added with iptables directly, which are not saved unless something persists them.
  • Anything started inside a tmux or screen session, which does not survive.
  • A pending kernel update, so you know whether this reboot changes the kernel too.

Reboot

sudo shutdown -r +1 "maintenance reboot"   # a minute of warning
# or now:
sudo systemctl reboot

After: prove it, do not assume it

systemctl --failed --no-pager
systemd-analyze blame | head
df -h
curl -sS -o /dev/null -w '%{http_code}\
' https://yourdomain.com
The best time to test a reboot is when nothing is wrong. A server that has been up for 400 days has 400 days of undocumented hand-made changes in it, and the first reboot finds all of them at once.
If the machine does not come back, you need console access from the provider panel - not SSH. Know where that button is before you need it.