Free memory climbed while one request hit 56 seconds during a package-update spike on a $0 n8n box

The memory reading is the part worth taking away from this run. Container memory fell from 252 MiB to 88 MiB in a single sample, and the first hypothesis was an OOM restart ^[16]. Docker disagreed: restarts=0, oomkilled=false, exit=0, seven weeks of container uptime, and no OOM in dmesg on a host up 54 days ^[17]. The drop was the kernel reclaiming page cache, which docker stats charges to the container ^[18]. Host free memory rose in the same window, 317 MB to 396 MB, precisely because reclaim was running under write pressure ^[22]. An alert threshold on free memory would have fired in the good direction ^[23].

What moved was iowait: 2.66% at 06:10, 20.20% at 06:30, 34.24% at 06:40, still 29.12% at 06:50 ^[20]. Dirty pages peaked at 41,316 kB ^[20]. User CPU over the same window went from 1.65% to 4.09% ^[21]. The journal names the cause: apt-news.service and packagekit.service started within a second of each other at 06:04, and PackageKit did not deactivate until 06:49 ^[19]. That is 45 minutes on a shared-core VM with a slow persistent disk ^[19][25], or 16% of the run ^[6]. The most expensive thing that happened to this workflow engine in five hours was its host reading the news.

Divide 10,577 by 1,673 and you get 6.32, so the published 6.3x tail improvement is a p95 figure measured against the seven-day baseline ^{[8][10][11][1]}. At p99 the gain is smaller: 3.1x against seven days and 4.7x against thirty ^[2]. The 56.7-second outlier is described as 93x the median for its bucket ^[15]; 93 is what the run-wide median of 610 ms gives you, while that bucket's own p50 was 715 ms, which makes it 79x ^[3]. Neither correction moves the direction.

The figure I would plan against sits in the same bucket. During the disk storm, with iowait above 34%, that half hour's p95 was 4,727 ms ^[15]. The identical workflow's p95 in ordinary idle operation over the prior seven days was 10,577 ms ^[8], so the loaded, disk-contended box was still 2.2x better at p95 than the quiet one ^[4]. Four sends out of 2,880 were refused, 0.14%, and they errored at the client rather than being accepted and then dropped, which is the distinction the harness exists to measure ^[6][5][1].

The explanation offered for the inversion is cold path: at 4.5 events an hour the instance is idle essentially always and each arriving request wakes something up, while a five-second cadence never lets anything go cold ^[3][12]. The author labels that a hypothesis rather than a finding, and says the claim is the table, not the reason ^[13]. Take it at face value. The table is one box, one workflow, 0.17 events per second, which the author says tells you nothing about 50 per second ^[5].

For the improvement to transfer, two things have to be true of your box: the p99 has to be dominated by wakeup cost on an idle instance rather than queue depth, and the host has to be one where a maintenance unit can take the disk for three quarters of an hour. Where both hold, the ugly tail on a low-traffic self-hosted service is an idleness cost and adding load would reduce it ^[14]. The graph that catches the real stall is iowait, which the author notes is absent from most default dashboards ^[23].