In both Debian 9 (stretch) and Debian 10 (buster), the process is started by the following two systemd timers:

• apt-daily.timer, which via apt-daily.service calls /usr/lib/apt/apt.systemd.daily update to update the package lists (apt-get update), and
• apt-daily-upgrade.timer, which via apt-daily-upgrade.service calls /usr/lib/apt/apt.systemd.daily install to install the upgrades (unattended-upgrade).

(The anacron job /etc/cron.daily/apt-compat still exists, but exits if it detects systemd. Without systemd, it will run /usr/lib/apt/apt.systemd.daily without sub-command, which means both update and install. See other answers or anacron documentation on changing the schedule if you don't use systemd.)

The systemd timers can be set to trigger at a higher frequency, in your example every four hours, by overriding the default schedule. First, for updating the package list:

$ systemctl edit apt-daily.timer
This creates /etc/systemd/system/apt-daily.timer.d/override.conf. Fill it as follows:
 
[Timer]
OnCalendar=*-*-* 0,4,8,12,16,20:00
RandomizedDelaySec=15m

Then, for the actual upgrades 20 minutes later:

$ systemctl edit apt-daily-upgrade.timer
 
[Timer]
OnCalendar=*-*-* 0,4,8,12,16,20:20
RandomizedDelaySec=1m

To check your work:

$ systemctl cat apt-daily{,-upgrade}.timer
$ systemctl --all list-timers apt-daily{,-upgrade}.timer

(Taken partly from Debian Wiki: UnattendedUpgrades.)

Für ein reboot am selbigen Tag um 23:00 könnte man folgendes als root ausführen:

systemd-run --on-calendar '23:00' -- systemctl reboot

solche run units werden im RAM gespeichert und laufen periodisch so lange bis zum nächsten reboot. Also falls man sowas für einen job verwenden will der nur einmalig triggern sollte (und nicht durch ein reboot eh resettet), einfach das Datum als YYYY-MM-DD vor der Uhrzeit hängen, etwa:

systemd-run --on-calendar '2023-02-08 23:00' -- systemctl reboot

Bei der Suche nach Platz benutzt man dafür meistens „du -sh /*|grep G“ .

Irgendwann bei der Suche, stolpert man über die großen Mengen Speicherplatz die in /var/log verwendet werden und hier ist i.d.R. der Syslogd der Platzkiller. Nun will man natürlich auch ältere Logs haben, damit darin nach Fehlern suchen kann. Insofern ist es ok, wenn die Logs etwas größer sind. Damit man aber schnell mal 2 GB Platz auf der Platte für andere Sachen gewinnt, kann man z.b. folgende Befehle benutzen:

journalctl --vacuum-time=10d
journalctl --vacuum-size=1G

Der erste Befehl löscht alle Logs, die älter als 10 Tage sind. Der zweite Befehl löscht alles weg, was mehr als 1 GB belegt. Ein 1 GB Log sollte für alle jüngeren Problemfälle reichen.

Jetzt könnte man die Größe des Logfiles in der Systemd Konfiguration dauerhaft hinterlegen, oder man nutzt den freien Platz nur temporär. Wenn man sich für letzteres entscheidet, darf man das Problem nicht auf die Lange Bank schieben, sondern sollte schnellstmöglich eine Entlastung der Platte durch Löschen anderer Daten herbeiführen.