I wanted to know what my laptop does while I sleep. On the night of 28 September one of my Claude Code sessions started a loop with whotop 0.4.1, whotop ls --all --json every 5 minutes until 8 in the morning. whotop is my own process inspector, I wrote it to find out what holds a port. The laptop runs Windows. My log does not record its build or the versions of Chrome, Postgres and Claude Code. The loop also wrote an index line per snapshot. If 2 snapshots were more than 7 minutes apart it marked GAP, so I would see when the laptop slept.
There is not a single GAP in the file. 96 snapshots, from 23:57 to 07:57 by the laptop clock, 303 to 305 seconds apart. A sleep shorter than a couple of minutes would not show, but the laptop did not sleep in any way I could see.
The machine was busy all night
The process count started at 486, went up to 510 at 00:13 and was 467 in the morning. The lowest was 460, at 03:14 and again at 06:21. Over the night the log saw 1615 different processes. 415 of them were there in every snapshot, so they lived the whole night. Everything else came and went. I counted a process as new when its start time is later than the first snapshot. The key is pid plus start time, because Windows reuses pid numbers. That gives 1129 new processes.
Before calling this noise I had to cut off the part that was not. Until 01:58 my agent sessions were still working, with builds and an ssh to a server that built there too. The last command was a production build at 01:58:56. After that no agent ran a command until the morning except the logger loop itself, so the quiet part of the night is 6 hours, from 01:59 to 07:57. In it the log caught 711 new processes.
The biggest source was the logger
I sorted the new processes by their parents and the largest group is whotop itself. Every snapshot is node, which starts PowerShell, which gets a console host, so 3 processes each 5 minutes. Over the whole night it is 285 of 1129, 25 percent. After 01:59 it is 216 of 711, 30 percent.
Then I checked when the other processes started relative to the logger and the share could be much bigger. On Windows whotop reads the process table with Get-CimInstance Win32_Process, the ports with Get-NetTCPConnection and the services with Get-CimInstance Win32_Service. All of this goes through WMI. WMI loads its providers into a separate process called WmiPrvSE. After 01:59 there are 70 new WmiPrvSE. 40 of them started between 0.39 and 0.56 seconds after the logger’s node. The same happened with bash in my Claude Code sessions. All 46 started 0.37 to 0.74 seconds after the logger and never at another moment. They came from 6 different sessions. Only one of them is the session that runs the loop. 28 console hosts started with them. If the logger sets them off, it is 330 of 711, 46 percent of the quiet part of the night.
What else woke up
Chrome is second. After 01:59 it started 169 new processes, 96 extension processes and 73 page renderers. That is 22 to 34 an hour until 8. The command line says --extension-process but not which extension, so I do not know which one restarts so often.
Windows itself started 97. Most are svchost, 69 of them. With the command line hidden I see only the name. Those with a clear name are more interesting. The Windows Modules Installer pair (TiWorker with TrustedInstaller) started 9 times over the night, 5 of them after 01:59, the last at 04:39. Search indexer processes came 7 times over the night, 4 of them after 01:59 and 3 of those between 07:26 and 07:35. CompatTelRunner, the compatibility telemetry, started at 03:19 and started a second copy of itself at 03:34. Microsoft describes maintenance as work that runs when the machine is idle and on AC power. That would fit if the laptop was plugged in, but the log does not say. I also did not log the Task Scheduler, so I can not say which of these starts were maintenance.
Postgres started 23 child processes, spread over all 6 hours. 5 of them also started right after the logger.
What lived through the night
Among the 415 residents there were 9 claude.exe processes, one of them a daemon. The oldest was started on 21 September, a week before. Dev servers had 43 processes with 14 listening ports between them. The oldest of them was started just after midnight on 25 September, almost 4 days before the log. I wrote whotop because I once killed the wrong node holding a port. The log does not say if any of these 14 was still needed.
What the log can not see
A snapshot every 5 minutes sees only what is alive at that moment. A process that lives 2 seconds between 2 snapshots is not in the log at all. This is where I went back and forth twice about the bash processes. First I took them as started by the snapshot, then I decided it was only the sampling. The timing above pushed me back. But a very short process started at random is also seen only if it runs during the query. So it would look tied to the logger too. The log can not separate these 2 cases. Chrome shows the random case for longer processes. Its 169 new processes were caught at all kinds of ages and never right after the logger.
978 of the 1129 new processes were seen in only one snapshot, so the real number of starts is higher. The logger also looks big partly because it is the only process guaranteed to be alive during every snapshot, so its 3 are never missed.
The log is also only a list of who runs. Resource use is not in it at all. whotop was not elevated, so in each snapshot 158 to 183 processes did not show their command line. For Postgres this means I can not tell autovacuum from a client connection. I logged only this one night.