DDoS Attacks Are Getting Faster. Is Your Business Ready for the First 10 Minutes?

When a business-critical website or application becomes unavailable, the technical cause is only part of the problem.

An eCommerce business may lose transactions. A SaaS company may have customers unable to use the service they are paying for. A professional services company may continue spending on advertising while enquiries quietly stop coming through.

For larger organisations, the impact can spread further into customer portals, APIs, internal systems and partner integrations.

This is why DDoS attacks should no longer be viewed simply as a network security issue. They are increasingly a business continuity and customer experience issue.

Cloudflare's H1 2026 DDoS Threat Report gives some useful context. During the first six months of 2026, Cloudflare says it mitigated 23.2 million network-layer DDoS attacks, including 935 attacks exceeding 1 Tbps.

Those numbers are significant, but one finding matters even more from an operational perspective:

90.6% of the network-layer attacks Cloudflare observed ended within 10 minutes.

For business and technology leaders, that changes the conversation.

The real challenge may be speed, not just size

Imagine a normal incident-response process.

Monitoring detects unusual traffic. An alert reaches the technology team. Someone investigates. The team determines whether the problem is infrastructure, application, DNS, security or something else. Then a decision is made about what to do.

There is nothing wrong with that process.

The problem is that, in a fast-moving DDoS incident, the attack may already have caused its disruption before the investigation is complete.

Cloudflare notes that some very large attacks can last only seconds, and that this leaves little practical opportunity for manual mitigation once an attack has started.

That does not mean people are becoming less important.

It means the first defensive response increasingly needs to happen automatically.

Your technology team should still investigate what happened, understand the impact and improve the environment afterward. But the infrastructure should ideally be capable of detecting and responding to abnormal traffic without waiting for someone to be available at exactly the right moment.

For a CTO, this becomes an architectural question.

For a CEO, it becomes a continuity question.

For a marketing leader, it becomes a customer acquisition question.

The same incident can affect all three.

You do not need to face a record-breaking attack to have a problem

The largest attacks naturally receive the most attention.

Cloudflare reported a 519% quarter-over-quarter increase in hyper-volumetric attacks exceeding 1 Tbps between Q1 and Q2 2026.

But most businesses should not build their security strategy around the question:

"Could we survive one of the largest DDoS attacks ever recorded?"

A more useful question is:

"How much abnormal traffic would it take before our own service starts to fail?"

Cloudflare says 96.62% of the network-layer DDoS attacks it observed during H1 2026 remained below 500 Mbps. It also points out that even comparatively small attacks can overwhelm infrastructure that is not designed to absorb them.

This distinction matters.

A global platform and a business website running on a single exposed server do not have the same capacity.

A SaaS application, an eCommerce platform, a corporate website and an internal customer portal also do not have the same risk profile.

Protection should therefore be proportionate to the business importance of the service, not simply based on the largest threat reported in the news.

Your server can be running while customers still cannot reach you

 

One finding in the report is particularly relevant for organisations that rely heavily on their websites and online services.

DNS-related attacks accounted for 34.3% of network-layer DDoS activity during H1 2026. Cloudflare also reported a sharp rise in CLDAP reflection and amplification attacks during the period.

Why should a business leader care about DNS?

Because your application can be healthy while your business is effectively unavailable.

Your server may be running.

Your database may be working.

Your internal monitoring may even show that everything is healthy.

But if customers cannot reliably resolve the domain and reach the service, none of that matters to them.

From their perspective, the website is down.

This is something we often see when organisations think about availability primarily in terms of server uptime.

Modern digital services depend on much more than the server itself. DNS, CDN infrastructure, APIs, third-party services, network routing, application health and the origin environment can all influence whether a customer can actually complete what they came to do.

A marketing campaign can be working while the website is failing

There is also a marketing implication that is easy to overlook.

Suppose a business is running paid search, social advertising, email campaigns or a major product launch.

Traffic increases.

The campaigns continue delivering visitors.

Advertising platforms continue spending the budget.

But the website becomes slow, intermittently unavailable or unable to complete important actions.

From the campaign dashboard, everything may initially look normal.

From the customer's perspective, the campaign has led them to a poor experience.

This is why website resilience should not belong entirely to the infrastructure team.

Marketing leaders should care about whether:

• Landing pages remain available under unusual traffic conditions
• Forms continue accepting enquiries
• Checkout remains functional
• Analytics and conversion journeys remain intact
• Security controls are not accidentally blocking genuine visitors
• Technology teams can identify availability problems quickly
  
  Performance, security and marketing effectiveness are increasingly connected.

So what should leadership teams review?

This report is not a reason for every business to launch an emergency infrastructure project.

The priority should depend on how important your digital services are to revenue, operations and customers.

But it is a useful reason to ask some practical questions.

Can traffic bypass your protective layer?

If a CDN, WAF or DDoS protection service sits in front of the application, can attackers still reach the underlying origin directly?

If they can, an important layer of protection may be easier to bypass.

How resilient is your DNS?

DNS is often configured during the initial website or infrastructure setup and then rarely revisited.

For business-critical systems, it deserves to be considered part of the availability strategy.

What happens when traffic suddenly increases?

Your infrastructure should have a predictable response to abnormal demand, whether that demand comes from a successful campaign, a legitimate traffic spike or malicious activity.

Are the most sensitive parts of the application protected differently?

Login pages, APIs, search functions, forms and computationally expensive requests may need different rate limits and controls.

Can mitigation happen without manual intervention?

If every incident requires an engineer to investigate before protection begins, response time itself becomes part of the risk.

Can genuine users still get through?

Effective protection is not about blocking as much traffic as possible.

It is about filtering malicious activity while allowing legitimate customers to continue using the service.

Will you understand what happened afterward?

Monitoring, logs and security data need to provide enough information to determine what happened, what was affected and what should change.

Having a CDN or WAF is not the same as having a resilience strategy

Businesses sometimes assume that enabling a CDN, Web Application Firewall or managed hosting service means the DDoS question has been solved.

Those technologies can be important, but the architecture and configuration around them matter just as much.

Depending on the importance of the platform, a sensible resilience strategy may include:

• DDoS mitigation at the network edge
• Reliable DNS infrastructure
• CDN and caching
• Web Application Firewall controls
• Rate limiting and bot protection
• Origin server protection
• Application and API monitoring
• Capacity planning
• Automated mitigation and alerting
• Incident-response procedures
• Recovery testing
• Post-incident review
  
  Not every organisation needs every control.
  
  A brochure website and a platform processing thousands of customer transactions every day should not necessarily have the same architecture or budget.
  
  The aim is not maximum complexity.
  
  The aim is appropriate resilience for the business risk.

Uptime is useful. Customer journeys matter more.

For years, website monitoring has often focused on a simple question:

Is the website up?

That question still matters, but it is no longer enough.

A better monitoring strategy should also ask:

Can customers resolve the domain?

Can they log in?

Can they search?

Can they submit an enquiry?

Can they complete checkout?

Are APIs responding correctly?

Are security controls accidentally blocking legitimate visitors?

A green uptime indicator does not automatically mean the digital business is functioning normally.

The more useful question is:

Can customers still complete the journeys that matter to the business?

That is where infrastructure monitoring becomes business monitoring.

What leaders should take away from this

The most useful lesson from Cloudflare's H1 2026 data is not that every company should expect a massive DDoS attack tomorrow.

It is that the window available for responding to modern attacks can be extremely short.

For organisations operating mature websites, eCommerce platforms, customer portals or SaaS applications, this is a good reason to review whether availability still depends too heavily on manual intervention or a single infrastructure component.

Technology teams should know how the environment behaves under pressure.

Leadership teams should understand which digital services are genuinely business-critical.

Marketing teams should know what happens to campaigns and customer journeys when those services become unstable.

And the organisation should agree in advance on how much resilience those services actually require.

Because when an incident can begin and largely finish within ten minutes, the best time to decide how your infrastructure should respond is before those ten minutes begin.