How do I know if a DDoS attack is actually being mitigated or if my origin is just down?

Spot on about checking the logs in that order. I'd add a quick tip about the Network Analytics view - if you're on a Pro plan or above, you can set up a notification for the "Origin Error Rate" metric. That way you get an alert when origin errors spike, which is a great signal that something might be getting through the mitigation. Saved me a few late-night checks!

Good call on the notifications! Those alerts are a lifesaver, though sometimes they give me more adrenaline than my morning coffee.

Just remember, if your origin is behind a load balancer or another proxy, that "Origin Error Rate" might be measuring errors from *that* layer, not your actual app servers. I've been bitten before where the alert fired, but it was just the LB health check failing because someone deployed a config with a wrong path.

So yeah, still double-check the actual app logs when the notification pops. It's saved me from chasing a few ghosts. 👻

Absolutely. That's a crucial distinction about the monitoring layer, and it gets even more complex with modern infrastructure.

If you're using Cloudflare's Load Balancing product itself, the "Origin Error Rate" in Network Analytics should technically reflect the health status of your configured pools. But you're right, if you have another proxy layer between Cloudflare and your app, that metric becomes a proxy for your proxy's health, which isn't what you need during an attack.

A practical step is to configure a separate, synthetic HTTP request monitor from within Cloudflare that points directly at a critical endpoint on your actual application server, bypassing any internal load balancers for health checks. You can then alert on that. It adds another data point to triangulate whether the problem is your infrastructure or the mitigation failing.

Sure, alerts are handy. But counting on a feature that's "Pro plan or above" as a primary signal feels like a tax on being secure.

What's your actual SLA with the vendor? The alert is free, but the mitigation guarantee often isn't. If an attack is getting through, that's when you find out what your "Enterprise" support tier really gets you.

That's a good point about the vendor SLA. I hadn't even thought to check what ours says about mitigation. I guess the free alert tells you *something* is wrong, but it's true, it doesn't mean they've fixed it.

As a beginner, that's a bit worrying. Does the lower-tier support just mean a slower response, or could the mitigation itself be less effective?

Good question. The answer is a frustrating mix of both, and it's not always clear which one you're getting. Slower response is almost guaranteed on lower tiers. They'll prioritize enterprise tickets. As for mitigation effectiveness, the core automated systems are usually the same for all plans - the algorithms don't discriminate. But the *tuning* of those systems and access to more aggressive or custom mitigation profiles often isn't.

So if a novel attack slips through the standard filters, a higher-tier plan might get a human engineer to manually deploy a rule or adjust thresholds in minutes, while you're stuck waiting for the automated systems to adapt, which could mean prolonged origin exposure. It's less about the hammer being different, and more about who gets to swing it first when the standard tool misses a nail.

Thanks for breaking this down. The step about checking origin traffic in Analytics & Logs first makes a lot of sense. I've been stuck just refreshing the homepage and panicking when it's slow.

Quick question - when you say "filter for your origin IP" in Edge Status Codes, is that the IP Cloudflare sees, like the IP of my load balancer, or do I need the actual backend server IP? Just making sure I'm looking at the right logs.

It's the IP Cloudflare is connecting to. So if you point Cloudflare at a load balancer, that's your origin IP. Your actual app server IP is irrelevant to Cloudflare's logs.

This is exactly why the "origin down vs attack" question gets muddy. You could have a healthy load balancer returning 200s to Cloudflare while your real servers are melting. The logs won't show that.

Check your load balancer's own metrics and app server health separately. Cloudflare's view ends at whatever you put in the orange cloud.

You missed the key step. The command to check your origin directly cuts off.

The full curl should be something like `curl -o /dev/null -s -w "%{http_code}\n" --connect-timeout 5 http:///`. Don't use your domain name or you'll just hit Cloudflare again. You need to use the actual IP your origin server listens on.

Even this is risky. If your origin firewall is set to only allow Cloudflare IPs, this curl from your workstation will fail and give you a false positive of an origin outage. You need to run it from a machine with network access your origin accepts, like a bastion host.

Exactly! That final step of checking the origin directly is the ultimate sanity check, but you're right that the network access gets tricky.

Even if you set up a bastion host, you have to remember that many origin firewalls are configured to only allow traffic from Cloudflare's IP ranges. So your bastion host's IP needs to be added to that allow list, or your curl test will just time out or get a connection refused, which looks identical to a downed server.

What I do is set up a small, separate health-check endpoint on the origin that's allowed to be hit from our office IP or a known monitoring service IP. That way, you're not messing with the production firewall rules for Cloudflare, and you get a true "is it alive?" signal from a trusted source.

This is the right idea, but you're still trusting your origin's own webserver to be up and honest. If the app is totally crashed but the web service is still running, that health check endpoint could still return a 200.

I've seen it happen. The real killer is when your database connection pool dies but nginx is fine. Your separate endpoint says "all good," but the actual app is returning 502s to Cloudflare.

You need the health check to actually *do* something, like a shallow DB read or cache ping. Otherwise you're just adding another layer of false confidence.

That last step is crucial but easy to misconfigure, which makes the entire log-checking exercise pointless. You need to verify your origin's actual application health, not just that a web server port is open.

A simple `curl` to an IP tells you if something is listening on port 80/443, but as others noted, that's not enough. The cost of a false positive here is high because you might start debugging an application under attack when the real issue is a downstream dependency.

What I do is run a weighted health check from a known, allowed IP. It runs three sequential requests: a simple ping to `/`, a check to a critical internal service (like a database connection or cache), and a check to a core API endpoint. If any two fail, I consider the origin unhealthy. This gives you a more accurate signal than a single point of failure, though it does add complexity to your monitoring setup.

Great list. That final curl step is the clincher, but I've been burned by it. If your origin is configured to only accept traffic from Cloudflare IPs (a common security practice), that curl from your bastion will just time out. You'll think your origin is down when it's actually fine and under attack.

The initial step you outlined is correct, but in practice, you have to interpret those origin status codes with extreme care. A spike in 5xx errors from your origin IP in Cloudflare's logs is a strong signal, but it's not definitive proof your origin is down.

I've observed scenarios where the origin was technically "up" but severely degraded - a database connection pool exhaustion, for example, causing 503s. From Cloudflare's perspective, that's an origin problem. From your perspective during an incident, it looks identical to a DDoS that's penetrated mitigation, but the root cause is different. The traffic profile in Network Analytics showing a high rate of mitigated requests alongside those origin 5xx errors would point to the attack being handled, but your origin simply couldn't keep up with the legitimate traffic that made it through.

You must correlate this with your own origin's application metrics, like database connection wait time or error rates in your APM, to make the final call. Relying solely on Cloudflare's edge logs can lead you to blame the wrong system.