Your application is already behind Cloudflare. The migration finished, traffic is flowing, and the team has moved on to the next release. Then an alert arrives during a busy afternoon. Requests are climbing, support has a report of intermittent failures, and someone asks whether the new campaign explains the traffic.
The first job is to establish what is happening. An attack, a successful promotion, an application fault, and an overbroad security rule can produce overlapping symptoms. You need enough context to separate them before a hurried change creates another problem.
Cloudflare’s H1 2026 DDoS report gives that work a sharper backdrop. The attacks it describes are a reason to revisit the assumptions behind your edge configuration, even when Cloudflare is already deployed.
Read the report at the right layer
Cloudflare recorded a combined 935 network-layer DDoS attacks exceeding 1 Tbps in H1 2026, with a +519% quarter-over-quarter surge in that class between Q1 and Q2. DNS-based attacks accounted for 34.3% of network-layer activity over the same period, and DNS Floods climbed from 25.7% to 40.0% of network-layer attacks quarter over quarter. Those figures describe activity observed across Cloudflare’s network, not the odds of an attack against your application. Cloudflare DDoS Threat Report, H1 2026
That distinction matters when you investigate. A network-layer flood and a burst of malicious checkout requests require different investigations. A WAF rule is not the control for every kind of DDoS event. Equally, a network mitigation event does not tell you whether legitimate customers can complete an application transaction.
Use the report to challenge your readiness. Check which services your deployment protects, which paths remain exposed, and whether the team can connect security events to actual customer impact.
Start with the traffic paths you actually have
The architecture diagram from go-live is a useful starting point. Compare it with the current application before relying on it during an incident.
A release may have introduced an API hostname. A supplier may have requested a DNS-only record. A temporary testing endpoint may still resolve to an origin. Each change can alter the route traffic takes and the protection that applies.
For every production hostname, establish its purpose, destination, and expected traffic path. Record whether it is proxied, which relevant Cloudflare services apply, and whether direct access to the origin is intentionally restricted.
Do not assume that moving authoritative DNS to Cloudflare places every service behind its application proxy. DNS hosting, proxying, and protection for other network services have distinct roles.
This review should produce a current map that an engineer can use under pressure. Put unresolved exposure or routing questions into a change record with an owner and a next action.
Give DNS changes operational context
The DNS-heavy activity in the report makes DNS resilience worth attention. It does not mean that every DNS-related failure is an attack.
An incorrect record, a delegation problem, or a change made without understanding cached answers can interrupt service while the security dashboard looks reassuring. During a traffic event, those ordinary faults make diagnosis harder.
Keep a record of consequential DNS changes: what changed, why it changed, who approved it, and how the result was checked. Include the previous value and any relevant TTL or dependency.
When investigating an incident, check resolution independently of application response. Establish whether the name resolves as expected, whether traffic reaches the intended destination, and whether the application serves a valid response there. Separating those checks prevents a DNS symptom from becoming an unnecessary WAF adjustment.
Tune application controls around legitimate behaviour
Your WAF and bot controls need context from the application team. A new mobile client, payment integration, or campaign landing page can change what legitimate traffic looks like.
Before tightening a rule, examine the affected hostname, path, method, and available request characteristics. Look for evidence of customer impact alongside the security event. Support reports, application errors, and failed transactions help explain what a rule match means.
Challenges need particular care on endpoints consumed by software. A browser page and a payment callback do not interact with a challenge in the same way. An action that appears reasonable in a dashboard can interrupt a valid integration.
Make changes narrow enough to evaluate. Record the intended result, the traffic that should remain unaffected, and the condition that would trigger rollback. Then verify both the security effect and the legitimate journey.
Rehearse the first incident decisions
An incident response rhythm begins before an alert. The on-call team should know where to find recent changes, which evidence to preserve, and who can approve an urgent adjustment.
The first update should describe the observed impact and the current hypothesis separately. “Customers report checkout timeouts” is an observation. “A DDoS attack is causing them” needs supporting evidence.
From there, investigate in parallel where staffing permits: review Cloudflare events, inspect origin health, check DNS and routing, and test an affected customer journey. Record timestamps so the team can compare the same window.
Avoid changing several controls at once without a clear reason. If service improves, you need to understand which intervention helped and whether it weakened another part of the application’s protection.
Turn the next quiet period into useful maintenance
After an event, retain the evidence that will make the next response easier. Capture the affected services, confirmed cause, changes made, and checks that established recovery.
Review temporary exceptions before they become permanent configuration. Feed new hostnames and application dependencies back into the traffic map. Update the runbook where the investigation stalled.
Use the H1 report as a prompt for maintenance you can do now: refresh the traffic map, tighten how DNS changes are recorded, and rehearse the first incident decisions. The largest attack figure is background. Your current paths and tested decisions decide what you can do when an alert arrives.
Vigilbase sells the Cloudflare licence and operates the account after go-live. We keep DNS, WAF, and incident work connected to the applications your customers use.
