It could definitely be stress-related, especially if you had a particularly bad night of sleep before this started.
When you don’t sleep well, your body can reset its cortisol production cycle. Cortisol—the hormone tied to stress and alertness—typically starts rising in the early hours of the morning, around 3–4 a.m., as part of a normal circadian rhythm.
But if you’re under even mild or subconscious stress, that spike can happen earlier or be stronger than usual, causing you to wake up prematurely and feel too alert to fall back asleep.
It’s like your body’s stuck in a “high alert” mode even if nothing obvious is triggering it.
Could be the birds that have already been mentioned as well, I am no expert, nor medical trained, but this reason is more common than you might think when waking up early. It’s the same reason you might find yourself waking before the alarm when you really need to be on time, like before going on vacation and you cannot miss your flight.
Here is a link to one of many in regards to sleep and cortisol
https://sleepdoctor.com/pages/health/cortisol
(edit: added part of the sentence that got lost before posting and figured I might add a link if someone wants to read more)
There are many good answers here already, just wanted to add to it.
It sounds very much like what you’re seeing could be either a driver fault or a memory-related issue. Both can manifest as hard system freezes where nothing responds, not even Ctrl+Alt+Fx or SysRq. You mentioned this briefly before, and that still fits the pattern.
If it’s a driver issue, it’s often GPU or storage related. A kernel module crashing without proper recovery can hang the whole system—especially graphics drivers like NVIDIA or AMD, or low-level I/O drivers handling your SSD or SATA controller. Checking dmesg -T and journalctl -b -1 after reboot for GPU resets, I/O errors, or kernel oops messages might reveal clues.
If it’s memory pressure or the OOM killer, that can also lock a machine solid, depending on what’s being killed. When the kernel runs out of allocatable memory, it starts terminating processes to free RAM. If the wrong process goes first—say, something core to the display stack or a driver thread—you’ll see a full freeze. You can verify this by searching the logs for “Out of memory” or “Killed process” messages.
A failing DIMM or a bad memory map region could also behave like this, even if Windows seems fine. Linux tends to exercise RAM differently, especially with heavy caching and different scheduling. Running a memtest86+ overnight is worth doing just to eliminate that angle.
If your live USB sits idle for hours without freezing, that strongly hints it’s a driver or kernel module loaded in your main install, not a hardware fault. If it does freeze even from live media, you’re probably looking at a low-level memory or hardware instability.
The key next steps:
Check system logs after reboot for OOM or GPU-related kernel messages.
Run memtest86+ for several passes.
Try a newer (or older) kernel to rule out regression.
If it’s indeed a driver or OOM event, both would explain the “total lockup” behavior and why Windows remains unaffected. Linux’s memory management and driver model are simply less forgiving when something goes sideways.