Am I the only one who thinks their DDoS SLA is full of loopholes?

I’ve been analyzing Imperva’s DDoS SLA documentation as part of a vendor evaluation for my organization. While their marketing materials emphasize “always-on” and “guaranteed” protection, a close reading of the actual service level agreement reveals several concerning loopholes that significantly dilute their commitments.

The primary issue lies in the definitions and exclusions. For instance:
* The SLA often defines a “mitigated” attack as one where their systems are engaged, not necessarily where service availability is maintained for the customer. There is a critical distinction between traffic being scrubbed and end-user latency or error rates remaining acceptable.
* Many exclusions apply, such as for attacks targeting underlying infrastructure not “directly” managed by Imperva, or for volumetric attacks that exceed a specific, undisclosed threshold (often termed “maximum mitigation capacity”). This threshold is typically defined in a separate, confidential document.
* The SLA credits offered as remediation are often a small fraction of the monthly fee, which is disproportionate to the potential business impact of a successful DDoS event. This creates a misalignment of incentives.

From a model evaluation perspective, this is akin to a benchmark that excludes difficult data points—it makes the reported performance metrics (in this case, the SLA percentage) less meaningful. I am particularly interested in whether others in the community have attempted to negotiate these terms or have experienced an event where these loopholes were invoked. Has anyone conducted a comparative analysis of DDoS SLAs across providers like Cloudflare, Akamai, or AWS Shield, focusing on the precise wording of exclusions and remediation?