Self-hosted n8n under sustained load: 2,880 events at a free-tier VM

Nothing was lost. Latency improved. The worst delay of the entire run was caused by the machine's own package manager, and it was invisible to CPU and memory monitoring.

We had published a 10-event burst result, and a reader replied that a burst and hours of elevated load are different animals. That is correct, and it is the better question. So on September 5 2026 we fired one event every 5 seconds for 4 hours and 42 minutes at the self-hosted n8n instance that runs our own benchmark harness: 2,880 events, 136x its normal hourly rate, held continuously, while sampling host telemetry every 15 minutes.

Read the scale honestly before the results. 0.17 events per second is a long duration at a modest rate. This is a test of whether a small box degrades, leaks or drops work over hours, and the answer is no. It is not a throughput benchmark, and it says nothing about 50 events per second. The workflow was our reference WF1: one webhook trigger, one outbound HTTP POST. A heavy multi-step workflow on the same box would be a different measurement.

Result

The four refusals are not counted in the failure rate, and that exclusion is deliberate. A refused send is a loud failure: our client got an error at the moment of sending, so it knows immediately and can retry. A silent failure is the opposite, an event that was accepted and then never arrived, with nothing anywhere reporting a problem. Mixing the two produces a number that means nothing. The reasoning is on silent failure vs rejected webhook.

Under load it got faster

The result we did not expect. Same workflow, same box, same receiver, compared against normal operation over the preceding 7 days:

The tail improved by a factor of 6.3 while the load went up by a factor of 136, and the effect holds against 7, 14 and 30 day baselines, so it is not an artefact of stale comparison data.

The likely explanation, stated as an explanation and not a measurement: at roughly 4.5 events per hour this instance is idle almost all the time, and each arriving request pays a cold-path cost. Under a steady 5-second cadence nothing gets a chance to go cold. If that is right, then for low-traffic self-hosted automation the tail you see in production is mostly an idleness cost, not a capacity cost. We have not run the experiment that would confirm it (fire one event after a long idle period, compare), so we are not claiming it as a finding. What we do claim is the comparison in the table.

The worst delay of the run was the machine cleaning its own house

Every 30 minutes of the soak, bucketed. Note the 06:30 row:

56.7 seconds, 93x the median for that bucket. Our first hypothesis was an n8n container restart, because container memory dropped from 252.5 MiB to 88.3 MiB in one sample, below its value at the start of the run. That hypothesis was wrong. The container reports restarts=0, started 2026-07-12, up 7 weeks, no OOM kill, and the host has been up 54 days. The memory reading fell because the kernel reclaimed page cache, which the container memory figure includes.

What actually happened is in the system journal. At 06:04:38 the machine's own apt-news.service started and activated the PackageKit daemon, which spent about 45 minutes refreshing package metadata before quitting at 06:49:49.

Disk I/O wait went from 2.7 percent to 34.2 percent for about 45 minutes on a shared-core VM with a slow persistent disk, and the request tail went with it. The load average of 2.72 we sampled at 06:36 fits: Linux counts processes blocked in uninterruptible disk wait toward load average, which is why a machine can show 4 percent user CPU and a load of 2.72 at the same time.

On a small free-tier VM, the operating system's own unattended housekeeping is a bigger perturbation than 136x your production traffic. Our load did not produce a single lost event in five hours. Its package manager produced a 56-second request.

And that incident was invisible to CPU and memory monitoring

This is the part worth carrying away. During those 45 minutes:

• CPU utilisation barely moved. User time went from 1.6 percent to 4 percent. The machine looked idle, because by CPU it was idle: it was waiting on disk.
• Free memory went up, not down. The kernel reclaimed page cache under write pressure, so available memory rose from 317 MB to 396 MB. A memory alert would have read this as an improvement.
• Only iowait showed it, and iowait is not on most default dashboards.

A monitoring setup watching CPU and memory would have reported a healthy machine for the entire window in which its p99 was 56 seconds. That is the same shape as the failure class this whole site exists to measure: the instrument was working correctly and reporting on the wrong layer. See uptime vs failure rate for the vendor-facing version of the same problem.

Four refusals we cannot explain, and a blind spot of our own

Four sends were refused, at 05:23:43, 05:23:58, 05:24:41 and 05:24:56 UTC. Sequence numbers 825, 826, 829 and 830 failed while 827 and 828 succeeded between them, so this was flapping, not a clean outage window.

We checked four sources for that moment and all four are quiet:

• CPU: 1.51 percent user, 3.07 percent iowait, 94.69 percent idle
• Network: 5.12 packets/s in, 1.52 kB/s in, flat across the window
• Container memory: 257.9 MiB, steady
• n8n's own container log for 05:20 to 05:30: empty

We do not know why those four were refused. Worse, we made it harder on ourselves: our harness recorded that each send failed but not why, because the error was caught and discarded. Connection reset, timeout and a non-2xx response are indistinguishable in our own ledger for these four events. We have fixed the instrument so the next run records the reason. A harness that measures other people's silent failures should not have a blind spot of its own, and reporting the gap is cheaper than pretending we know.

Method

• Target: self-hosted n8n in Docker on a Google Cloud e2-micro (1 GB RAM, 0.25 vCPU baseline, 2 GB swap), the same instance that serves our production benchmark harness. Free tier, no cost.
• Workload: reference WF1, one Webhook trigger to one outbound HTTP POST.
• Rate: one event every 5,000 ms for 4h42m, 2,880 events total, 0.17 events/s.
• Measurement: each event is written to our ledger before sending; the workflow posts to our receiver, which records arrival. Latency is receiver arrival minus fire timestamp, so it includes n8n processing and both network legs.
• Host telemetry: sampled every 15 minutes during the run; post-hoc attribution from sar (10-minute resolution) and journalctl.
• Cohort hygiene: every event carries a WF1soak tag and is excluded from the headline numbers on our reliability and latency pages. A stress test must never share a denominator with normal operation.

Limits of this result

• One box, one config, one workflow shape. Nothing here transfers to a heavy multi-step workflow, a queue-mode deployment, or a different host.
• Duration, not throughput. 0.17 events/s sustained for five hours. We did not test peak rate.
• The cold-path explanation is unconfirmed. The latency comparison is measured; the reason for it is a hypothesis.
• The four refusals are unexplained, and our instrument could not have explained them.
• A single run. One soak on one day. The apt-news window in particular is a scheduled event we happened to catch, not a rate.

Questions