Define what is unavailable and when it changed
Start with the business symptom: the whole site is unreachable, only checkout times out, administrators cannot log in or one integration fails. Record the first observation, timezone, affected routes and sources of the report. One monitoring location can fail for reasons that do not affect every customer.
Compare with a relevant baseline. Traffic, cache behavior and resource use can differ during campaigns, scheduled jobs or routine business peaks. A recent release or provider issue may coincide with a traffic increase. Preserve those alternative explanations until the evidence supports narrowing them.
Identify the technical owner, hosting provider and edge-provider contacts. If service is impaired, coordinate proportionate operational action while collecting evidence. Do not create a live traffic spike, repeatedly submit orders or invite others to “test the attack” as part of an informal diagnosis.
Compare competing explanations rather than counting symptoms
Use several signals tied to the same interval. Request distribution, routes, methods, response errors, application work and database behavior help explain which component is under pressure. The most visible chart may describe only part of the path.
The original matrix below keeps plausible alternatives and the next evidence together. It is not a formula that classifies every outage automatically. Record uncertainty when the logs, metrics or relevant baseline are missing.
| Observation | Another plausible explanation | Evidence to compare next |
|---|---|---|
| Request count rises | Marketing activity or expected automated access | Affected routes, distribution, timing and normal traffic pattern |
| CPU or database pressure rises | Expensive query, job or application change | Process, query, release and resource timeline |
| Only checkout fails | Gateway delay or integration defect | Route-specific logs and provider evidence |
| Many edge mitigations occur | Protection acting on traffic before the origin | Origin load and actual customer impact in the same interval |
| Origin is busy without the same edge spike | Another route, background work or infrastructure issue | Coverage, host/network evidence and job schedule |
| One uptime probe fails | Probe location, resolver or monitoring-route issue | Independent authorized observations and service telemetry |
Know which traffic the edge dashboard actually describes
Cloudflare distinguishes HTTP and network-layer protection and analytics. The relevant view depends on the product and traffic path. Its documentation also describes plan-dependent visibility and situations where a handled request or packet does not expose a public managed-rule identifier.
Do not equate edge request totals, origin access logs and host network traffic without understanding their populations and timing. Cached or mitigated traffic can have different origin effects, while an unprotected route or background job may not appear in the expected edge view at all. Check which hostnames and services are actually covered.
Cloudflare describes using multiple request, packet and response signals for DDoS detection. That explains the provider’s approach; it does not prove that the symptoms on a particular website are an attack. A provider alert is relevant evidence to correlate with business impact, not a replacement for understanding the affected service.
Check origin work and business dependencies
Review recent application, component, database and infrastructure changes with the responsible administrator. A resource bottleneck may arise from legitimate traffic made expensive by a regression, a job that runs unexpectedly or a downstream service that delays responses. The corrective action depends on that cause.
For a store, distinguish browsing from cart, checkout, server notifications and fulfillment. Some routes cannot be cached like public content, and some automated callbacks are necessary business traffic. A blanket challenge or restriction can make a chart look quieter while breaking a required process.
Keep inspection proportionate and authorized. Use existing telemetry and controlled observations before proposing load testing. Any performance or security assessment that generates significant traffic needs a separate scoped plan, provider coordination and clear limits. This diagnostic guide does not authorize live stress tests.
Choose mitigation for the layer and verify legitimate work
The responsible providers may need to address network saturation, HTTP traffic patterns, application work or an external dependency. Use the controls appropriate to the evidenced problem. A WAF rule is not every network protection mechanism, and scaling resources is not proof that malicious activity has been addressed.
For a suspected false positive or a protection adjustment, define the permitted workflow, scope and review conditions. Verify the intended route and the protection boundary with controlled checks. Keep a record of what improved and what remains unexplained instead of closing the case solely because the homepage responds again.
Close with evidence, limits and owned follow-up
Record the affected interval, systems observed, relevant signals, provider findings, authorized changes and functional verification. Separate a confirmed attack, a suspected attack and an unresolved outage. Where metrics are sampled, missing or unavailable, preserve that limitation in the conclusion.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide. Our practical Israeli website and infrastructure knowledge helps connect Cloudflare, hosting, application and integration evidence within an agreed scope. Describe the URL, affected workflow, timing and available provider reports. Do not send secrets or customer payloads with the initial enquiry.
After service is stable, assign monitoring and remediation actions that address the actual gap: a coverage issue, inefficient workflow, rule mismatch or incident-control problem. The objective is a defensible diagnosis and maintainable response, not an attack label for every traffic peak or a promise that one protection product prevents every outage.
