Protecting a website against DDoS requires controls on the traffic path, a clear escalation route and a way to check that legitimate visitors can still use the site. If an incident is happening now, establish what is failing and contact the provider responsible for the affected layer before making broad changes.
Slowness or an outage alone does not prove a DDoS attack. Application errors, an exhausted resource limit and a legitimate traffic spike can produce similar symptoms. The immediate task is to preserve useful evidence and restore service without blocking real users unnecessarily.
Start an incident record
- Record the start time and timezone, affected hostname or service, observed errors and whether the problem affects all users or particular regions.
- Compare current traffic, resource use and errors with a normal period, using the monitoring and logs available to you.
- Check recent deployments, configuration changes and provider status information. Do not assume that coincident traffic proves the cause.
- Contact hosting, network or protection support with the affected service and evidence. Keep credentials and private customer data out of ordinary diagnostic messages.
Keep one person responsible for recording changes. If several teams change filtering, DNS and the application simultaneously, it becomes harder to determine which change restored service or caused a new problem.
Match the control to the problem
Traffic can exhaust network capacity or application resources. A rule on the origin server cannot recover an upstream connection that is already saturated; that situation needs assistance before the traffic reaches that connection. Application-layer rules address a different part of the path.
Cloudflare's DDoS documentation distinguishes protection across layers, while its WAF documentation describes filtering web requests. These explain the mechanisms; they do not establish that a particular Cloudflare feature is included in a WebCare360 service.
A CDN can reduce origin work for cacheable content, but cache misses, personalized pages and direct access to the origin still need attention. Ask which hostnames, IP addresses and protocols the chosen protection actually covers.
Make reversible changes and test real journeys
Use the protection service's documented incident controls with the responsible operator. Record a rule's purpose, scope and rollback method before applying it. Broad country blocks or aggressive request limits can disrupt real visitors, integrations or users sharing an address.
After each change, test essential journeys such as login, forms and checkout from representative clients. Check both availability and rejected legitimate requests. If origin access must be restricted behind a proxy, confirm the provider's current trusted-source requirements and preserve needed administration access before changing firewall rules.
Prepare for the next incident
- Maintain an inventory of public services, their traffic paths and the team responsible for each.
- Record normal traffic and application behavior so an incident has a comparison point.
- Keep escalation contacts and account access available to the people who will respond.
- Review coverage gaps and false positives after the incident, using the actual timeline.
- Maintain patching, access control and recoverable backups separately; DDoS mitigation does not replace them.
For a coverage decision, use the DDoS hosting coverage and limits guide. For current WebCare360 options, check DDoS-protected hosting and confirm the scope for your service. No mitigation arrangement should be read as a promise that an application cannot become unavailable.
