A traffic drop is not always DDoS: separate network and application failures
Correlate outage context, provider status and site telemetry to locate failures.
Contents of this article
A curve records a change, not its cause
Radar distinguishes outage observations and corroborated events. For an individual site, falling traffic can also reflect DNS, certificate, deployment or policy problems. A decline alone does not establish an attack or regional outage.
Build one timeline across layers
Align DNS, TCP/TLS, edge responses and origin health with recent deployments and configuration changes. Record network and client differences, and cross-check from independent locations because the monitoring path can also fail.
Locate the failure before switching
DNS failures, policy false positives and origin overload need different responses. Before failing over, validate alternate certificates, origin permissions and capacity. Change one major factor at a time where practical and record the result.
Validate the complete journey
After the homepage returns, test sign-in, APIs, uploads and callbacks. Watch for retry-driven database or queue overload. Keep external status context alongside local changes and recovery times in the incident record.
References
Cloudflare Radar outage definitions