← BenchTruth

How fast do automation platforms actually deliver?

Measured end to end on the identical workflow · 14,994 timed deliveries · updated 2026-09-03 · no affiliate links on this page

On the identical webhook-to-action workflow, self-hosted n8n delivers fastest at the median (969 ms) and Zapier slowest (4.29 s), a 4.4x gap. The ranking inverts in the tail: Make is the steadiest platform we measure (99th percentile 3.04 s), while n8n's tail stretches to 16.57 s because it runs on a deliberately small 1 GB VM. Being fast on average and being reliably fast are different properties, and only one of them shows up in a median.

Vendors publish uptime, not delivery time, and nobody publishes percentiles. These numbers come from our own continuously running harness: we stamp every event when we fire it, the platform runs an identical workflow, and it POSTs back to our receiver, which records arrival. Both ends are ours, so the network path is the same for everyone and no third-party connector sits in the middle.

Delivery latency, full percentiles

PlatformDeliveries timedp50p90p95p99Fastest / slowest seen
n8n (self-hosted) - 1 GB free-tier VM12,975969 ms3.26 s6.24 s16.57 s208 ms / 56.22 s
Pabbly Connect - free tier, small sample44784 ms1.27 s1.33 s1.46 s555 ms / 1.50 s
Make - paid plan6631.01 s1.23 s1.31 s3.04 s408 ms / 4.04 s
Pipedream - free tier, pre-quota-wall1192.72 s4.50 s4.88 s5.28 s479 ms / 5.48 s
Zapier - paid plan1,1934.29 s6.66 s9.81 s29.21 s1.47 s / 67.57 s

Sorted by median. Sample sizes differ by design - the self-hosted platform carries the bulk sample because it costs nothing to run, while paid platforms get smaller samples, so read the tails on small samples loosely. Pipedream's figures are from before its free-tier quota wall (documented on the reliability page). Raw per-run data with individual timings is downloadable at the bottom of this page.

What the numbers actually say

Method and limits

FAQ

Which automation platform is the fastest?

It depends entirely on whether you mean typical or worst case, and the answer flips. On the identical webhook-to-HTTP workflow, self-hosted n8n has the fastest median delivery (969 ms) and Zapier the slowest (4.29 s), a 4.4x gap. But at the 99th percentile the ranking changes: Make is the most consistent (3.04 s) while n8n's tail stretches to 16.57 s because it runs on a deliberately small 1 GB VM that occasionally queues under load. Fast on average, occasionally slow, is a different product than steady.

Why does p99 latency matter more than the average?

Because averages hide the runs that hurt. If one delivery in a hundred takes 17 seconds instead of one, the median tells you nothing about it, but a user staring at a form or a downstream system with a timeout absolutely notices. Percentiles also expose architecture: a consistent p50-to-p99 spread usually means queueing behaviour, while a huge spread means resource contention. We publish p50, p90, p95, p99, min and max for exactly this reason, rather than a single 'average latency' number that would flatter everyone.

How is this latency measured?

End to end from our side: our controller stamps an event with the time it fires it, the platform's webhook receives it, runs an identical workflow, and POSTs back to our own receiver, which records arrival time. The difference is what we publish. Both endpoints are ours, so no third-party connector sits in the path, and the network route is identical for every platform, which makes the numbers comparable with each other. They are not comparable with a vendor's internal benchmark, which typically measures only the time inside its own system.

Is self-hosted n8n faster than Zapier?

In our measurements, yes for typical deliveries and no for the worst ones. Median: 969 ms versus 4.29 s. But in the tail the advantage disappears: n8n's 99th percentile (16.57 s) is worse than Make's (3.04 s), and the honest reading is that our n8n runs on an intentionally minimal 1 GB VM, so its tail measures our hardware choice as much as the software. A larger box would likely tighten it. That caveat is the point: self-hosted latency is a function of what you host it on, which is precisely the trade-off self-hosting asks you to own.

Raw data

Every timed delivery, per run: benchtruth-runs.csv · CC BY 4.0 · cite as "BenchTruth latency dataset, benchtruth.com/automation-latency-benchmark".