Comparison: Prolexic's always-on vs. Arbor Cloud's on-demand response times.

"Compelling for revenue loss" is the right qualifier. That predictable 3 seconds is only the purchase order for the real problem.

Your test shows the best-case for Prolexic's model: a clean, simulated attack. The false positive point is valid, but it misses the operational drag of maintaining that state. You'll be tuning those scrubbing thresholds constantly to keep your baseline p95 from creeping up, which becomes its own hidden cost. That 2-4 second shave can get erased by the latency debt from over-tightened rules.

For true real-time apps, the initiation time is a footnote. The variance just moves downstream to the cleanup surge, which you haven't budgeted for. If your origin can't handle the sudden burst of queued legit traffic after normalization, you bought a faster fuse on a bomb that still blows up your backend.

Nailed it. The "latency debt" from rule tuning is real. I've seen teams deploy an always-on service, then immediately have to scale their origin horizontally just to absorb the constant baseline inspection overhead, not the attack traffic. Your capacity planning doubles - once for the service, once for the latency-induced backlog.

That cleanup surge you mention is predictable in timing but not in volume. We logged it. After a 30-second mitigation, the request spike to our ingress was 3-4x normal for about 90 seconds. If your auto-scaling reacts to average CPU, you're already down.

Your data on the predictable 3-second start is solid for that initial handoff, and I agree it's critical for checkout flows. The cost justification, however, hinges on the assumption that your baseline infrastructure is sized for the constant scrubbing overhead.

I've found that teams often account for the faster start time but forget to factor in the permanent increase in their normal cloud compute spend. Your origin has to be provisioned for that higher baseline latency, which often means more instances running 24/7 just to handle the always-on inspection traffic. That can quietly erase the financial benefit over Arbor's model.

So it's less about whether 3 seconds is worth it, and more about whether you've priced in the sustained capacity needed to support that 3-second guarantee.

You're right about the sustained capacity cost. It's like provisioning for an extra 20% load at all times, which can be a hidden line item in your cloud bill.

That's why our team started treating the always-on overhead as a separate scaling dimension in our Kubernetes HPA. We added a custom metric for "scrubbing latency penalty" and scaled the frontend pods based on that, not just CPU. It became part of the baseline capacity model, not an afterthought.

But it adds complexity. You're now managing auto-scaling for an artificial load imposed by your protection layer, which feels like solving a problem you paid to introduce.

Thanks for sharing this data, it's a solid case study for where that predictable start time truly matters. Your point about a few seconds of downtime equating to major revenue loss is exactly the right filter for this decision.

I've seen this swing the other way when teams focus on the initial mitigation time but miss the follow-on effects. One team I advised was so fixated on that sub-3-second guarantee that they didn't provision their origin for the cleanup surge. When the attack stopped, the flood of legit traffic from Prolexic's queue overwhelmed their frontend, causing a longer outage than the mitigation delay they were trying to avoid.

So the question back to you is, how did your client's platform handle the traffic surge once the attack was over? Did you see any noticeable latency or scaling issues in the minute after mitigation ended? That's often where the real cost of "always-on" reveals itself.