Most DDoS attacks last seconds to minutes, though repeat waves can keep a site unstable for hours or, in stubborn cases, days.
If you’re trying to size up a DDoS event, the honest answer is this: there isn’t one fixed clock. Some attacks burn hot and fade in under a minute. Others come in bursts, switch methods midstream, and keep a site limping long after the first spike passes.
That gap between the raw attack time and the real business impact is what trips people up. A flood can be short. The outage can still drag on while caches refill, rate limits stay tight, upstream filters settle, and teams sort out what broke under pressure.
So when someone asks how long a DDoS lasts, they usually mean one of three things: how long the hostile traffic keeps hitting, how long the service stays slow or unavailable, and how long it takes to feel normal again. Those are not always the same number.
What A DDoS Duration Actually Means
A distributed denial-of-service attack is built to drown a target in traffic, requests, or connection attempts until real users can’t get through. That pressure can hit the network edge, the web layer, the DNS layer, or all of them in a nasty mix.
When duration gets reported, vendors often mean the period during which attack traffic was detected. Operations teams may mean the service disruption window instead. Owners and editors usually care about the reader-facing impact: the span when the site was slow, flaky, or flat-out gone.
That distinction matters. A site can stay up through a short attack if the defenses are ready. A site can also go down from a modest attack that lasts longer than it should because the stack is underbuilt, misconfigured, or missing upstream help.
How Long Does A DDoS Last On A Live Site?
On a live site, plenty of DDoS attacks are brief. Cloudflare said 90% of DDoS attacks in its 2024 Q3 data were short-lived, while attacks lasting more than an hour made up only 3% of the total. That tells you something useful: a lot of these events are fast, sharp bursts, not marathon floods.
Still, “brief” doesn’t mean harmless. A 45-second or 2-minute burst can smash login pages, checkout flows, APIs, or origin servers if the site has thin headroom. Google has also described record-scale HTTP floods that peaked fast, with one widely cited event lasting only two minutes at its crest while the broader incident ran far longer.
In practical terms, most DDoS events land in one of these buckets:
- Seconds to a few minutes: short pulse attacks, burst floods, test strikes, or automated barrages that hit hard and then stop.
- Ten minutes to an hour: common for brute-force traffic waves, repeated HTTP floods, and attacks that keep rotating source IPs or request patterns.
- Several hours: more likely when the attacker keeps changing vectors, the target has weak upstream filtering, or the site relies on a narrow infrastructure path.
- A day or more: less common as one continuous wall of traffic, but still possible when attacks return in cycles or the recovery work lags behind the traffic itself.
The raw length is only half the story. Two sites can face the same 20-minute flood and end up with wildly different outcomes. One shrugs and serves pages the whole time. The other spends half a day cleaning up.
Why DDoS Attacks Stretch Or Fizzle Out
The first driver is attack type. A blunt volumetric flood is loud and easy to spot, which can make it easier for modern mitigation systems to block at scale. A thinner application-layer attack may send fewer packets yet cause more trouble because it imitates normal user behavior and chews up server work.
The second driver is attacker behavior. Some groups launch one hard burst to test your edge. Some keep swapping tactics. A UDP flood may turn into a SYN flood, then shift into HTTP request abuse once the first filters clamp down. Every change can buy the attacker more time.
The third driver is your stack. A site behind a mature CDN or scrubbing provider usually reaches a steadier state faster than a site that takes traffic straight to origin. Rate limiting, anycast reach, autoscaling, caching, web application firewall rules, and DNS resiliency all change the clock.
The fourth driver is human response. If nobody knows what normal traffic looks like, the team wastes time guessing. If the runbook is ready and upstream contacts are lined up, the same event can feel shorter because the response starts at once.
| Factor | What It Does To Duration | What It Looks Like In Practice |
|---|---|---|
| Attack layer | Layer 3/4 floods can be huge but easier to spot; Layer 7 traffic can drag because it blends in | Massive packet spike vs slow, costly page-request flood |
| Traffic pattern | Burst attacks may end fast; pulsing attacks can keep a site unstable for longer | Thirty-second spikes every few minutes |
| Vector switching | Extends the event by forcing fresh filtering and tuning | UDP flood shifts into HTTP request abuse |
| Mitigation at the edge | Shortens visible impact by absorbing traffic before origin feels it | CDN or scrubbing network blocks junk upstream |
| Origin capacity | Weak origin headroom turns short attacks into longer outages | CPU pins, database pool stalls, pods restart |
| DNS resilience | Weak DNS can make the outage feel longer than the flood itself | Site stays unreachable after traffic drops |
| Runbook quality | Clear steps cut response time and reduce spillover damage | Rate limits, geo blocks, and escalation happen fast |
| Upstream coordination | Fast ISP and provider help can end the pain sooner | Blackholing or filtering starts early |
Why A Short Attack Can Cause A Long Outage
This is where site owners get blindsided. Attack traffic drops, yet the site still crawls. That can happen when the event exposes a weaker part of the stack. Connection pools may stay saturated. Queues may stay backed up. Autoscaling may launch extra nodes that then trip a different limit. Caches may have been flushed, which sends a fresh wave of work to origin.
You also get the human cleanup window. Teams tighten firewall rules, block regions, disable certain features, or lower thresholds to stay safe. Those changes can protect the site while still making some pages slower or some users fail challenges for a while.
CISA’s DDoS guidance frames response as more than blocking packets. It pushes planning, dependencies, communications, and recovery work because service health after the flood matters just as much as packet counts during it.
What Shapes Recovery Time After The Flood Ends
Recovery time rides on what the attack touched. If the event stayed at the network edge and never stressed origin, recovery can be near instant. If databases, message queues, login services, or third-party APIs got dragged into the mess, the cleanup window grows.
There’s also the matter of false positives. Teams under pressure often tighten controls hard. That can block bad traffic, but it can also catch real readers, buyers, or app users. Rolling those rules back takes care. Nobody wants to reopen the door too soon.
The recovery path usually follows a plain sequence: stabilize, verify, tune, and then widen access. The cleaner that sequence is before the attack starts, the shorter the pain after the packets stop.
How To Tell Whether The Attack Is Still Active
Do not rely on one graph. A single metric can lie to you. You need traffic volume, request rates, response codes, latency, origin resource use, and upstream provider alerts side by side.
If inbound traffic is back near baseline but latency stays high, the attack may be over while the service is still recovering. If traffic keeps arriving in sharp bursts after each rule change, the attacker may be probing your edges and waiting for a gap. If DNS, CDN, or firewall logs still show blocks climbing, the event is still live even if the website looks “sort of okay” from one region.
That’s why teams with baseline data move faster. AWS notes in its anti-DDoS best practices that defenses work better when they have time to learn normal traffic patterns ahead of an event. AWS anti-DDoS best practices stress normal-period setup for the same reason: reaction is sharper when the system knows what “normal” looks like.
| Signal | What It Usually Means | Likely Timing Read |
|---|---|---|
| Traffic spike drops fast | Short burst or blocked wave | Attack may be ending |
| Latency stays high after traffic falls | Back-end recovery issue | Outage can outlast the attack |
| Repeated spikes every few minutes | Pulsing attack or probing | Event may stretch for hours |
| 403/429 counts jump while origin steadies | Filters are catching more junk | Mitigation is taking hold |
| CPU, memory, or DB load stays pinned | Application stress remains | Recovery still in progress |
| CDN healthy, origin failing | Attack may have shifted inward | Traffic shape changed, not ended |
What Site Owners Should Expect In Real Terms
If your stack already sits behind a capable edge network with sane rate limits, caching, and a tested incident path, a lot of DDoS events will feel short. Readers may never notice. You may only see a blip in logs and a tense half hour in the ops channel.
If your site exposes origin, depends on a fragile plugin stack, or has no upstream plan, even a moderate attack can eat half a day. Not because the hostile traffic is still huge, but because every weak spot starts showing itself at once.
That’s why “How Long Does A DDoS Last?” has a two-part answer. The traffic often lasts minutes. The business impact lasts as long as your weakest dependency takes to recover.
How To Shorten The Next One
Get the boring stuff done before you need it. Put the site behind an edge service that can absorb floods upstream. Cache pages that should be cached. Rate-limit expensive paths like search, login, checkout, and API endpoints. Lock in provider contacts and an incident checklist. Test failover and origin shielding while the site is calm.
Also, split your thinking by layer. Network floods, HTTP floods, and DNS abuse each leave different footprints. If you treat every DDoS as one generic blob, you lose time right where you can least afford it.
A short attack is still a warning shot. If one pulse already caused pain, the next wave may last no longer and still hurt more. The smarter move is to trim recovery time, not just hope the next attacker gets bored sooner.
References & Sources
- Cloudflare.“DDoS Threat Report for 2024 Q3.”Provides reported attack-duration patterns, including the share of attacks that were short-lived and the small share that lasted more than an hour.
- CISA.“Understanding and Responding to Distributed Denial-of-Service Attacks.”Supports the response and recovery sections by outlining planning, dependencies, mitigation, and post-incident handling.
- AWS.“Best Practices for Anti-DDoS.”Supports the point that baseline traffic knowledge and prebuilt defenses help shorten visible impact during an attack.