Record the approximate incident time and timezone. Confirm authorized access to system logs, which may contain personal or sensitive data. Determine whether persistent journal storage was enabled before the incident; missing historical data cannot be recreated afterward.

1. Run journalctl --list-boots to identify retained boot IDs and their time ranges. Select the actual incident boot instead of assuming every previous index refers to the event you want.
2. Inspect journalctl -b -1 for the immediately preceding retained boot, or use the explicit boot ID. Narrow by time and unit to reduce unrelated noise.
3. For kernel and hardware clues, inspect kernel messages from that boot. Look for storage errors, OOM events, watchdog reports and orderly shutdown messages near the end.
4. Correlate with application logs, provider events and maintenance history. An abrupt log ending can suggest lost power or a crash, but it is not conclusive proof by itself.
5. Export the relevant bounded interval to protected storage and sanitize excerpts before sharing. Configure appropriate persistent retention for future incidents after considering disk capacity and privacy.

Run this from an administrative shell on a Linux server using systemd-journald. Begin by listing stored boots, then select the previous boot. These commands do not reboot the server or change journal retention.

sudo journalctl --list-boots
sudo journalctl -b -1 -p warning --no-pager -n 80
sudo journalctl -k -b -1 --no-pager -n 80

Read the result: The boot index -1 selects the boot before the current one. Compare the end time of that boot with shutdown messages, storage errors and service failures. Missing previous-boot output often means persistent journals were unavailable or older records were rotated; it does not prove that no error occurred.

Use the log timestamps alongside the provider event history and monitoring. A sudden end without a shutdown message can have several explanations, including abrupt power loss or logging failure. Preserve the evidence before another reboot makes the timeline harder to compare.

The previous boot may not have been retained, persistent storage may have been disabled, or permissions may restrict access. Enabling persistence now helps future incidents but does not recover old entries that were never stored.

Confirm timestamps align across guest, host and monitoring systems. Distinguish a clean requested shutdown from an unexpected stop using several sources where available. Record which logs were present and which were unavailable so the conclusion does not overstate certainty.

If no earlier boot appears, check journald storage configuration and rotation policy. Do not invent a cause from the absence of logs. Repeated disk errors or corruption need storage investigation before another reboot or forced repair. Retain the current evidence before changing retention settings.

• Investigating a failed systemd service
• Investigating an out-of-memory process kill on Linux
• Responding to a Linux filesystem that became read-only
• Verifying Linux time synchronization and timezone

• Debian manual: Journalctl.1.en
• Debian manual: Journald.conf.5.en