We've been using Imperva for a few months now, and overall, the security posture is solid. But we're running into a major operational issue with their DDoS mitigation.
Our site handles a decent volume of traffic, including predictable spikes. The problem is that the threshold for triggering their DDoS mitigation seems to be set incredibly high. We've had two incidents now where our origin server was overwhelmed by what looks like a volumetric attack, but Imperva didn't kick in until the damage was done—resulting in full outages for several minutes.
This feels counterintuitive. We chose a WAF/DDoS service precisely to *prevent* outages, not just to mitigate after we're already down.
Has anyone else experienced this? I'm trying to figure out:
* Is this a common configuration challenge?
* Are the default thresholds just not suitable for mid-sized businesses?
* What's the best way to work with their support to calibrate this? We've opened tickets, but the process feels slow.
I'm curious if others have built any external monitoring or automation to bridge this gap. For instance, using an external uptime tool to ping Imperva's API and adjust settings if our origin starts to slow down? It feels like we shouldn't have to, but I'm exploring all options.
This is a known configuration gap with many managed DDoS services. The default thresholds are often calibrated for very large, sustained attacks to avoid false positives, which directly conflicts with protecting a finite origin capacity.
Your approach of external monitoring is correct, but pinging their API is reactive. The method I've validated involves pre-emptive, automated threshold adjustments based on your own origin metrics. You need to define your origin's actual saturation point (e.g., 80% of bandwidth, or 90% of HTTP worker threads), then use their API to lower the mitigation threshold to a value below that point, *before* a spike hits. You can script this using your observability platform's webhook and a simple cron job that polls Imperva's API for the current threshold settings.
Their support can be slow because they operate on a "break glass" model. The key is to present them with your own capacity data and request a permanent baseline threshold adjustment. Frame it as a capacity issue, not just a security rule. Include graphs of your origin's load during the outages versus the threshold line from their logs. Without that data, you're just in a queue for a generic review.
Test it yourself.
That's a solid technical approach, and framing it as a capacity issue to support is key. I've seen teams get stuck for weeks going back and forth on "attack signatures" when the real problem is just the threshold versus origin headroom.
One caveat on the automation: be mindful of who owns the API credentials and how you version control that script. I've seen a well-intentioned automation loop get tripped up after a vendor API update, inadvertently locking thresholds at an ultra-low level and causing a different type of outage. Building in a periodic reset to a safe baseline, or at least an alert on script failure, is worth the extra effort.
Review first, buy later.
That API credential point is super important, thanks! It's easy to forget that the automation itself can become a single point of failure.
I'm curious, what do you consider a "safe baseline" for the reset? Is it just the vendor's default, or something a bit lower that you've manually vetted? Trying to think about how to build that in without losing all the proactive benefit.
Yeah, it's super common. The defaults are often set for massive networks, not mid-market origin capacity. It's a classic "false positives vs. protecting your actual servers" trade-off.
Working with their support is slow, but push them to talk about your *origin's max capacity* (requests/sec, bandwidth) as the benchmark, not their typical attack thresholds. Frame it as a business continuity issue.
External monitoring to trigger the API is a good band-aid, but the real fix is getting them to set a permanent threshold well below your saturation point. Had to do this with a client last year - once we showed the support rep our server metrics during an "almost-outage," they adjusted it pretty quickly.
—b
Exactly what you're describing is a classic sign that your service is protecting *their network*, not your business. The defaults are absolutely not suitable for mid-sized origins. They're tuned to ignore noise and only stop attacks that would threaten a massive, distributed platform, not your finite server capacity.
When you work with support, stop talking about "attacks" and start talking about your *business continuity SLA* and your *origin's concrete saturation metrics*. Show them a graph from your last outage where your server's CPU, bandwidth, or connection pool hit 100% while their mitigation was still idle. That shifts the conversation from a security debate to a clear operational failure on their part to meet your service objective. It's much harder for them to deflect.
A quick band-aid while you push that through: set up a simple external health check on your origin's critical user-facing endpoint (like the login or checkout page), not just a ping. If the response time degrades beyond a threshold you know precedes an outage, that's your trigger to manually engage their support via a pre-written escalation path. It's not elegant, but it creates a documented paper trail for the business impact.
Yes, it's common and yes, their defaults are usually unsuitable for mid-sized origins. Their thresholds are tuned for *their* network capacity, not yours.
The slow support process is predictable. Stop framing it as a security false-positive discussion. Go in with your origin's capacity data. Show them the exact request rate or bandwidth where your servers fail. Demand they set the threshold permanently below that point. If they argue, escalate it as a failure to meet your availability SLA.
External monitoring is a temporary workaround, not a solution. You're paying them to handle this, not to build your own mitigation system on top of theirs. Use the data from your monitoring to prove the threshold is wrong.
Five nines? Prove it.