DDoS flood
The DDoS flood is the first incident in SysAdmin Crisis: traffic from non-customer addresses and a bandwidth bar going red. Learn its log signature.
Last updated:
A flood is the first incident the game teaches, and the only one that can appear on night one. Traffic arrives from addresses that are not customers, the bandwidth bar fills, and everything behind it starts to suffer.
What it does
The attack ramps up over roughly fifteen seconds of real time instead of arriving all at once, so you get a window between the first odd line and the first red bar. At its peak it aims at 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 go into
saturation: CPU climbs to 99%, latency rises, and roughly every fifteen seconds
one more target drops to DOWN.
The log signature
A flood does not announce itself by name; you see the symptom as kernel and monit lines on the edge machines. The lines below are examples, and the values change every night:
03:11:42 web-02 kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters.
03:11:45 web-02 monit[612]: 'web-02' cpu usage of 94% matches resource limit [cpu usage > 90.0%]
03:11:49 web-02 kernel: nf_conntrack: nf_conntrack: table full, dropping packet
These lines do not tell you the source. netstat and the web
access log show who is sending requests; summarising the log with grep,
awk, and sort | uniq -c is the real work of this incident. 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 by one. 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 SYN warnings from the kernel; a runaway process is a single named process on a single machine. |
| Memory leak | A leak climbs RAM, not bandwidth, and shows no traffic signature. |
| Overheating | Heat can arrive after a flood as a secondary 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, never two |
| Variant | from night 6 a flood may arrive distributed: five sources spread across the three RFC 5737 blocks instead of a single address |
The distributed variant is decided by the seeded PRNG, so the same seed produces the same night every time — see determinism and seeds.