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

Phone support is a security blanket, not a lifesaver. By the time you get someone on the line at 2 AM, the automated systems have already blocked the attack or you're already toast. Their ticket response for actual emergencies is fast, faster than most vendors will get you a human.

Your bigger risk is your team not knowing their own rule sets. If you're relying on a phone call to walk you through it, you've already lost.

I hear you, the lack of a phone number does feel wrong at first. I was in your shoes a couple years back.

Here's my experience: we got hit with a massive spike of what looked like credential stuffing. The automated alerts from Cloudflare fired immediately, which was the main thing. I logged a ticket marked "Emergency" around 1:30 AM, and a human actually responded in about 15 minutes. They helped confirm it wasn't a false positive on our rules.

The real lesson for us was setting up those internal playbooks beforehand. If you're waiting for any vendor's support, phone or ticket, you're already reacting too slow. Run some tabletop exercises with your team on what the dashboard is telling you.

It's a mindset shift, for sure. But once you build the internal muscle memory, the ticket system feels less risky.

Exactly this. That 15 minute response on an emergency ticket tracks with what I've heard from colleagues. The ticket system actually creates a written record, which is way better than trying to explain a complex attack vector over the phone while stressed.

Your point about playbooks is spot on. We did something similar. Our rule was: the first person to see the alert checks the playbook. If it's a known pattern, we execute. If it's totally new, then we hit the emergency ticket button. It turns the support ticket into a strategic escalation, not a panic call.

The mindset shift took us a few months, but now I actually prefer it.

That phone line you want is a placebo. You dial it, you get put on hold listening to bad music while some tier 1 reads a script. Meanwhile, the actual attack is happening.

Cloudflare's emergency ticket gets a real engineer fast because they're not wasting time on the phone. Your team's panic isn't their problem to manage, it's your problem to fix with a playbook. If you need hand-holding, you're not ready for a WAF.

That's a good point about the written record. I hadn't thought about how messy it would be trying to describe an attack over the phone while it's happening.

Can you share what you put in those first-response playbooks? I'm trying to build ours and I'm stuck on the basics. Like, what's the first thing someone should actually *do* when an alert pops up at 2 AM? Just check the dashboard for the source IPs?

Great question. Our playbook starts with verifying it's a real attack, not a false positive from our own automation. First step is to check the Firewall Events tab for the top user agent and ASN. If it's all one ASN, we can block it at the IP level immediately as a stopgap.

Then we look for the rule ID that triggered. If it's a Cloudflare Managed Rule, we know it's likely a real attack and we let it ride. If it's one of our custom rules, we check its recent history - sometimes a recent deploy triggers something we didn't expect.

The key is to have those dashboard paths documented. Like "Go to Security > WAF > Events, filter by date and action." Saves precious minutes when you're bleary-eyed.

You're right to think about that 2 AM scenario, and that initial worry is completely normal. Your feeling about needing a direct line is really about needing confidence that you won't be left alone.

I'll echo that their emergency ticket response is genuinely quick. I've had a similar 15-minute response on a holiday weekend. But the more important thing for your team's confidence isn't the ticket speed - it's building the muscle memory before an emergency happens.

That means running a few practice drills. Have someone on call trigger a test alert, then walk through logging a mock ticket while another person checks the dashboard. Doing that even once will show you the actual timeline and reduce that feeling of being exposed. The security comes from your team knowing their first three moves by heart, not from hoping a voice on the phone will guide them.

The practice drill idea is crucial. We made ours a quarterly exercise tied to our internal audit. The key metric we track isn't response time to the ticket, but the time from alert to the first *correct* diagnostic action in the dashboard.

We found the biggest delay was people forgetting how to filter the Events log effectively. So now part of the drill is performing three specific filters under time pressure. For example: "Find all 408 responses triggered by Managed Rule 100048 in the last 10 minutes."

> The security comes from your team knowing their first three moves by heart

Agreed, and we formalized those moves into a checklist that lives in our incident commander's runbook. Move 1 is always "Identify the top 3 attacking ASNs." It removes the paralysis because it's a concrete, repeatable task. The ticket is just move 4.

So your team built that muscle memory over a few months. That's the real cost, right? The migration cost from a 'someone else's problem' mindset to owning your own config. Not everyone's team can afford that ramp-up time when they're already firefighting.

The written record is a double-edged sword. It's great for post-mortem blame assignment. But sometimes a five minute voice call can clarify a fuzzy situation faster than a dozen ticket updates. The bias towards tickets assumes your team can articulate the problem perfectly while under fire.

You're right about the ramp-up cost, it's real. But if your team is already firefighting, that's the core issue no support model will fix. A phone call might soothe the immediate panic, but it doesn't build your team's capability.

The ticket forces clarity. If you can't articulate the problem in writing, you probably don't understand it well enough to fix it, even with a five minute call. The back-and-forth in the ticket is the diagnostic process.

Invest the few months. The alternative is permanently renting out a part of your brain to a vendor's support line.

Your first step to check for a single ASN is a solid triage move. I'd add that while a single ASN block is a great stopgap, the next diagnostic layer should be checking if that ASN is a known hosting provider or residential ISP. Automated attacks from places like OVH or DigitalOcean can look monolithic in the ASN view, but they're often spanning hundreds of unique IPs within that ASN. A block at the ASN level might be too broad.

For the custom rule check, we go a step further and log the last 10 triggers of that rule to a separate dashboard before any deploy. That way, the person on call has a baseline of "normal" activity for that rule to compare against immediately, rather than digging through generic event history.

That's a really smart escalation step. Spotting a single ASN feels like a win until you realize it's Hetzner and you're about to blackhole a chunk of legitimate European traffic.

Your pre-deploy baseline dashboard is genius. We track rule velocity generally, but isolating the last 10 triggers per custom rule before a change is much more surgical. It turns a fuzzy "is this normal?" into a yes/no check. Do you find that baseline gets stale quickly, or is ten triggers usually a recent enough snapshot?

Okay, I'm in the same boat looking at them for a CRM tool. The phone support thing scares me too.

But everyone here is saying the ticket system works fast, even at night. Is that really true for all their plans? Or is the quick response only if you're paying a lot?

That initial worry about the 2 AM scenario is totally valid. I had the same hesitation years ago.

My experience matches others here - the emergency ticket response is real. I've had a major false positive block our main API endpoint, and a human responded in under 20 minutes on a Sunday. But more importantly, they immediately helped me craft a more precise custom rule to replace the overly broad one, which was the actual fix.

That said, you're right that it's a different kind of risk. The trade-off is you're betting that your team can provide clear, actionable diagnostics in a ticket at 2 AM instead of panicking on a call. If that's a concern, building that checklist *before* you need it is non-negotiable.