Every mitigation leaves a record: which rule fired, what threshold it crossed, what the traffic was made of, and a packet capture you can open in your own tools without taking our word for any of it. This page shows the shape of that record, and states plainly what the numbers in it can and cannot support.
Below is an incident record in the format you receive. It is an illustrative example, not a real customer event.
| UDP, source port 53 (DNS responses) | 58.2 % |
| IP fragments, no transport header | 41.8 % |
| Distinct source addresses sampled | 6 480 |
| Distinct source networks (/16) | 1 902 |
| Mean frame size | 1 392 B |
| TTL distribution | consistent with initial 64, 6-15 hops |
21:04:39.118204 IP 198.51.100.24.53 > 203.0.113.19.41288: UDP, length 1416 0x0000: 4500 05a4 0000 4000 3711 ... f1e8 8380 0001 00 21:04:39.118231 IP 192.0.2.201.53 > 203.0.113.7.52104: UDP, length 1408 21:04:39.118255 IP 198.51.100.77.53 > 203.0.113.212.9931: UDP, length 1421 [ 41.8 % of frames in this capture are fragments and carry no port numbers ]
The same four things, whatever the vector, so records can be compared to each other and to your own monitoring.
Which rule fired, what its threshold was and by how much it was exceeded. Not a severity colour - the actual number and the actual limit, so you can tell a rule that was nearly wrong from one that was obviously right.
What the traffic consisted of: protocols, source and destination ports, packet sizes, TTL distribution, fragment share and how many distinct sources and networks were sampled. Enough to tell spoofing from a botnet without asking us.
A packet capture in ordinary pcap format, openable in Wireshark or tcpdump. We would rather you checked. An operator that shows you only its own summary is asking you to trust the summary.
Start, end, duration and burst count, measured from when traffic crossed the threshold rather than from when somebody noticed. A pulse-wave attack that stops and returns eleven times is one incident with eleven bursts, not eleven incidents.
Rates are sampled, not counted packet by packet. Telemetry is statistical, so a figure is an estimate with an error bar that widens as the rate falls. At high rates it is tight; for a small attack the sample count is what limits it, and the record says how many samples stood behind the figure.
Bandwidth is per destination, not per vector. Byte counters are kept per destination address. When several things arrive at once, the volume figure is the destination's total - the record says what share of the packets the firing rule accounted for, and below a high share that total should not be attributed to the attack.
A peak is a peak, not a sustained rate. The headline figure is the busiest measurement window in the incident. Averaging it across the duration gives a very different and much smaller number, and both are in the record for that reason.
Some attacks are not classified. Where a vector cannot be qualified from the traffic, the record says so rather than guessing a label. An unclassified attack is still mitigated and still counted; it simply is not evidence about a vector.
We do not publish other customers' events. No prefix, no address and no customer from one account appears in another's reporting, or on this website.
Attack history for your prefixes, with the record and the capture attached to each event.
The same records over REST, for pulling into your own monitoring or incident tooling.
During an incident, from the engineer on the NOC line who is already looking at it. Not a ticket queue and not an autoresponder.
This site sets zero cookies - no analytics, no trackers, no profile of you. The only third-party requests are the fonts, served by Google Fonts, and the spam check on the contact form. Everything else stays between your browser and our network - the full privacy note.