DDoS flood
One address, thousands of requests a second, and a bandwidth bar going red.
Last updated:
A flood is the first incident the game teaches, and the only one that can appear on night one. Traffic arrives from an address that is not a customer, the bandwidth bar fills, and everything downstream of it starts to suffer.
What it does
The attack ramps over roughly fifteen seconds of real time rather than arriving all at once, so you get a window between the first odd line and the first red bar. At peak it aims for just under the fleet's total bandwidth capacity — which means capacity matters, and a bigger fleet genuinely absorbs more.
Once demand passes about 1.35× capacity, the machines behind it start
saturating: CPU climbs toward 99%, latency rises, and roughly every fifteen
seconds one more target drops to DOWN.
The log signature
The [fw] tag is the tell. An address repeats with a request rate no real
client produces, and the user agent is a bare dash:
03:11:42 [fw] 203.0.113.7 — 4200 req/s (UA: "-")
03:11:45 [web-02] cpu saturation warning (94%)
03:11:51 [web-03] service unresponsive — marked DOWN
The signature reprints every eight seconds or so, so it survives a busy log
stream. Every address in the game comes from the RFC 5737 documentation
blocks — 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 — so an address
outside those blocks is never an attacker.
If you leave it alone
Bandwidth saturates first, then CPU, then machines start going down one at a time. A downed server is sticky: it does not come back on its own. And because an unresolved incident starts accruing SLA debt once its grace window expires, a flood you ignore costs uptime twice — once through the machines it takes down, once through the clock. See escalation and SLA.
Telling it apart
| Looks similar | What separates it |
|---|---|
| Runaway process | A flood's CPU pressure is fleet-wide and arrives with [fw] lines; a runaway is one named process on one host. |
| Memory leak | A leak climbs RAM, not bandwidth, and shows no traffic signature at all. |
| Overheating | Heat can follow a flood as a second-order effect. If both are running, the temperature is a symptom, not the cause. |
When it shows up
| Earliest night | 1 — it is also the tutorial's second lesson |
| Needs | at least one web machine in the fleet |
| At once | one flood at a time, never two |
| Variant | from night 6 a flood may arrive distributed: five sources spread across all three RFC 5737 blocks instead of one address |
The distributed variant is decided by the seeded PRNG, so the same seed produces the same night every time — see determinism and seeds.