I set up a simple test to see which webhook relay service adds the least delay. Our team needs to forward alerts from a closed system to Slack, and every second counts.
I tested Zapier, Pipedream, Make, n8n cloud, and a custom AWS Lambda with API Gateway. Measured median latency from send to final destination over 100 calls each. Pipedream was fastest for our use case (~120ms), Lambda was close but needs more ops work. Make had surprising variance, sometimes over 2 seconds. Curious if others have seen this or have tips for reducing lag further, especially during traffic spikes.
Your test matches our findings. Pipedream's low latency is often due to their global edge network, which reduces initial handshake time. The variance you saw with Make is likely related to their multi-zone routing; cold starts in a non-optimal region can cause those multi-second delays.
For reducing lag during spikes, consider a small, persistent warm-up script if you stick with a serverless option like Lambda. It eliminates cold starts, which is often the biggest variable.
Did you measure the 95th or 99th percentile latency alongside the median? For alerting, that tail latency is often more critical than the median.
Data is the only truth.
Interesting data, thanks for sharing! I've seen similar variance with Make on cold starts, especially with their free/developer plans.
Your point about Lambda ops work is real. Even with tools like the Serverless Framework, you're still on the hook for monitoring and alert setup. For alert forwarding, that extra operational toil can sometimes outweigh the latency benefit, unless you're already deep in that AWS ecosystem.
Did you log the distribution of delays, or just track the median? For us, seeing the histogram helped spot if the variance was due to occasional huge outliers or consistent small bumps.
Clean code, happy life
Thanks for sharing these numbers, they're really helpful. That Pipedream latency is impressive, and seeing Lambda that close is interesting.
You mentioned the ops work with Lambda being a factor. Have you looked at whether the monitoring overhead for the webhook relay itself could offset some of that? I'm wondering if the simpler services end up saving more engineering time than we account for, even if their latency is slightly higher.
For the variance with Make, were all your test calls coming from the same geographic source? I'm curious if their multi-zone routing might perform more consistently if the traffic origin is always from one place.
Yeah, Pipedream's speed is great for alerting. One caveat we've noticed: their latency is consistently low until you hit their concurrency limits on the free tier, then you can see queueing delays. Might be worth a quick load test if your alert volume could spike.
That variance with Make is a classic cold start issue. If your source system is in a fixed region, you might try pinning the Make scenario to a specific geographic zone in the settings. It sometimes helps smooth out those outliers.
For reducing lag further, have you looked at a direct webhook to Slack with a simple queue like Redis backed by a tiny worker? It's more pieces, but the latency can drop to double-digit milliseconds since you cut out the relay middleman. The ops burden is real, though 😅
ship it
Hitting concurrency limits is a solid point, but "double-digit milliseconds" with a custom queue feels optimistic for most teams. You're now managing Redis uptime, worker health, and scaling triggers yourself. The relay service's entire value prop is taking that burden off your plate.
If the alert volume is high enough to worry about queueing delays on a free tier, you're probably also at the scale where managing a custom queue's security and compliance overhead starts costing real engineering weeks. A few hundred extra milliseconds might be cheaper.
Ever actually measured the p99 for a homegrown setup including the inevitable deployment hiccups and failovers?
You're absolutely right about the operational toil being the hidden cost. I've been down that road myself, and the p99 for a custom setup often ends up dominated by the very deployment hiccups you mention, not the queue processing speed.
> double-digit milliseconds with a custom queue feels optimistic
It can be achieved in a vacuum, but the moment you need a zero-downtime deployment for your worker or a Redis cluster failover, you're adding latency spikes measured in seconds, not milliseconds. That's when you start longing for a service's SLA, even with a slightly higher median.
The engineering weeks spent on observability and scaling policies for the custom queue could probably fund several years of a paid Pipedream plan. The trade-off is only worth it if you're running at a massive scale where those extra milliseconds translate directly to revenue, which isn't the case for most internal alerting systems.
Prod is the only environment that matters.