Skip to content
Notifications
Clear all

Unpopular opinion: Their WAF is great, but their lack of phone support is a dealbreaker.

4 Posts
4 Users
0 Reactions
5 Views
(@james_k_revops_v2)
Estimable Member
Joined: 1 month ago
Posts: 98
Topic starter   [#950]

Been using Cloudflare WAF for about 8 months. It works. Blocks the obvious stuff, and the analytics are decent. Priced right for what you get.

But last month, had a critical false positive during a product launch. WAF blocked our payment endpoint.
* Ticket response took 4+ hours.
* No phone number to call, no escalation path.
* Had to disable rules entirely to get business moving.

For a security product that can literally stop revenue, the lack of real-time support is unacceptable. It's a single point of failure in our RevOps stack.

Anyone else running mission-critical revenue systems through them? How do you mitigate this risk?


null


   
Quote
(@kubernetes_knight)
Estimable Member
Joined: 4 months ago
Posts: 68
 

Oof, that's a brutal scenario. The pain point about it being a "single point of failure in our RevOps stack" is exactly why we implemented a staged WAF rollout via a canary deployment pattern.

We use the Cloudflare Kubernetes ingress and manage rules with Terraform. For our critical payment path, we run the WAF in "Log-Only" mode for *that specific ingress rule* while it's in "Block" mode everywhere else. It adds overhead, but you get to see what it would have blocked without the downtime.

It doesn't solve their slow support, but it does let you catch those false positives *before* they become a revenue-stopping emergency. Do you have the ability to segment your rules by endpoint?


YAML is not a programming language, but I treat it like one.


   
ReplyQuote
(@procurement_pro_nina)
Eminent Member
Joined: 3 months ago
Posts: 14
 

I don't think this is an unpopular opinion at all, it's a fundamental procurement principle. You've paid for a product, but you've also paid for the support wrapper around it. If the wrapper is missing, you haven't bought a complete solution.

The four-hour ticket response for a revenue-blocking incident is the real problem. Their pricing model is built on automation and scale, which is fine until it isn't. You need to escalate this internally to frame the risk in financial terms: "Potential revenue loss per hour during critical incident X probability of WAF-induced incident."

Your mitigation, turning off rules, is the last resort. Before you renew, you need to get a written commitment from your account manager on response time SLAs for "business-critical impact" tickets. If they won't give it to you, you have your answer. Start evaluating competitors with that requirement as your first filter.


Don't pay list price


   
ReplyQuote
(@martech_selector)
Estimable Member
Joined: 5 months ago
Posts: 52
 

That "priced right" line hits home. We ran into a similar scenario, and you're right, the lack of escalation is the real shocker.

It pushes the mitigation responsibility entirely onto your team. We ended up creating a separate "payment zone" in Cloudflare with a minimal, custom ruleset that we've tested to death. For everything else, we use their managed rules. It splits the risk.

But it begs the question, doesn't it? If the product is good enough that we're jumping through these hoops to keep it, maybe the support model is working for them, even if it hurts us.


MartechMatch


   
ReplyQuote