I think I had observed this for the last three (or so) kernel updates:
When the system boots the new kernel after a kernel update, the system reboots
unexpectedly about at the moment when the filesystems were all mounted.
Unfortunately there is no trace in journal or messages of that failed boot.
However "last" seems to record those. I have:
reboot   system boot  5.14.21-150400.2 Wed Nov  2 09:21   still running
reboot   system boot  5.14.21-150400.2 Wed Nov  2 09:20 - 09:20  (00:00)
reboot   system boot  5.14.21-150400.2 Tue Oct 18 07:59 - 09:19 (15+02:19)
reboot   system boot  5.14.21-150400.2 Tue Oct 18 07:56 - 07:57  (00:00)
reboot   system boot  5.14.21-150400.2 Fri Sep 23 12:07 - 13:00 (7+00:53)
reboot   system boot  5.14.21-150400.2 Fri Sep 23 12:05 - 12:05  (00:00)
reboot   system boot  5.14.21-150400.2 Thu Sep 15 12:08 - 12:04 (7+23:55)
reboot   system boot  5.14.21-150400.2 Thu Sep 15 12:07 - 12:07  (00:00)
reboot   system boot  5.14.21-150400.2 Tue Aug 16 08:55 - 11:57 (30+03:01)
reboot   system boot  5.14.21-150400.2 Tue Aug 16 08:46 - 08:54  (00:07)
reboot   system boot  5.14.21-150400.2 Thu Jul 28 07:43 - 08:22 (19+00:38)
reboot   system boot  5.14.21-150400.2 Sun Jul 24 16:31 - 23:07 (3+06:36)
reboot   system boot  5.14.21-150400.2 Sun Jul 24 16:20 - 16:30  (00:09)
reboot   system boot  5.14.21-150400.2 Fri Jul 22 23:39 - 16:19 (1+16:39)
reboot   system boot  5.14.21-150400.2 Mon Jul 18 14:38 - 14:58 (4+00:19)
reboot   system boot  5.14.21-150400.2 Thu Jul 14 12:07 - 10:09 (3+22:02)

You see that starting around August 16th, there are two boots within rather
short time (a boot here takes some time as I have to enter passwords for
encrypted filesystems three times, and GRUB's decryption is rather slow, too).

You also see that the new kernel version strings are not quite compatible with
"last" (they are too long).