I load-tested self-hosted n8n on a $0 VM for 5 hours. The worst latency came from apt.

I run a benchmark harness that measures how often automation platforms silently drop webhook events. The self-hosted part of it lives on a Google Cloud e2-micro: 1 GB RAM, 0.25 vCPU baseline, 2 GB swap, free tier, $0/month. It handles about 108 events a day, roughly 4.5 an hour, and has been up since July. Someone pointed out that the burst test I had published (10 events at once) says nothing about sustained load, which is true and is the better question. So I held one event every 5 seconds against it for 4 hours and 42 minutes. 2,880 events. 136x its normal rate, continuously, while sampling host telemetry every 15 minutes. Scale caveat before anything else, because 136x sounds more impressive than it is: 0.17 events/second is a long duration at a modest rate. This tests whether a small box degrades or leaks over hours. It is not a throughput benchmark and tells you nothing about 50/second. Nothing broke fired 2,880 accepted 2,876 refused at send 4 (loud, client errored) accepted then lost 0 (silent) Zero lost in five hours. No memory leak, no progressive slowdown, no queue backing up. That's the boring headline and it's the one I expected. It got faster, which I did not expect Same workflow, same box, compared against normal operation: median p95 p99 normal, last 7d (n=260) 782 ms 10,577 ms 16,937 ms normal, last 30d (n=1120) 822 ms 10,322 ms 25,517 ms under soak (n=2876) 610 ms 1,673 ms 5,392 ms The tail improved 6.3x while load went up 136x, and it holds against 7, 14 and 30 day baselines, so it isn't a stale-comparison artifact. My explanation is cold path: at 4.5 events an hour the instance is idle essentially always, and every arriving request has to wake something up. Under a 5-second cadence nothing gets a chance to go cold. I'm labelling that a hypothesis, not a finding. The experiment that would confirm it is trivial (fire one event after six hours idle, compare) and I haven't run it. What I'm claiming is the table, not the reason. If it does hold, it's a mildly uncomfortable thought for capacity planning on low-traffic self-hosted services: the ugly p99 you see in production may be an idleness cost rather than a capacity cost, and adding load would improve it. Then, at 06:30, a 56-second request Thirty-minute buckets across the run: bucket fired refused undeliv p50 p95 worst 04:00 253 0 0 521 1728 32,831 04:30 319 0 0 581 796 4,032 05:00 308 4 0 608 782 13,100 05:30 319 0 0 579 783 2,445 06:00 314 0 0 590 2174 5,617 06:30 273 0 0 715 4727 56,726