A DDoS attack rarely announces itself. What you see first is a slow site, a paging alert, or a customer complaint — the same symptoms as a bad deploy, a database lock, or a viral post. The teams that recover fastest are the ones that can classify the event in minutes rather than argue about it for an hour.
The Seven Signals
- Request rate jumps far beyond your normal peak, but conversions and signups stay flat — real demand moves both numbers together.
- Traffic concentrates on one path. A flood usually hammers a single URL, often the homepage, a search endpoint, or a login form.
- The origin server is busy but the database is idle: connections pile up in the web tier while queries per second barely move.
- Response times climb while CPU on the application server sits low — the bottleneck is connections and sockets, not computation.
- Source addresses are geographically or topologically improbable: a regional business suddenly served from dozens of unfamiliar networks.
- User agents are uniform, missing, or oddly outdated. Real browser populations are messy; botnets are monotonous.
- The pattern is too regular. Human traffic breathes with the working day; floods are flat lines or square waves.
Fast test
Compare requests per second against orders, signups, or logins per minute in the same window. If request volume multiplies and business events do not, you are looking at automation, not customers.
What Not to Do First
The instinctive responses are usually the wrong ones. Restarting the web server clears the queue for a few seconds and then refills it. Scaling up the origin buys capacity that the attacker can consume faster than your bill can absorb. Blocking a handful of noisy addresses by hand is satisfying and almost never material, because the source set is usually far larger than the addresses that reached your log tail.
The First Ten Minutes
- Confirm the classification with the two-number test above, and write the time down. Every later step is measured from this moment.
- Raise protection to a challenge mode so unverified clients must prove they are a browser before reaching the origin.
- Check that your origin is not reachable directly. If the attacker has the origin address, filtering at the edge does nothing.
- Capture evidence while it is still happening: peak request rate, target paths, response codes, and a sample of source networks.
- Tell the people who will be asked — support, sales, and anyone on call — what is happening and what to say.
After It Stops
An attack that ends is not an incident that is finished. Keep the evidence, write a short postmortem while the detail is fresh, and check the one thing that most often turns a repeat attack into an outage: whether your origin address leaked at any point during the response.