Skip to content
PEERYXNETWORK
Mitigation evidence | Attacks actually filtered | Peeryx
Mitigation evidence

Real attacks, real measurements

Announcing a capacity proves nothing. Here is what our filtering servers actually handled, measured by their own telemetry, with the counting method and the limits of the exercise.

The record

27 699Attacks mitigated
3.12 GppsLargest peak handled
93attacks above 100 Mpps
46 sMedian duration

Measurement period : → (95 days)

Detection does not stop

Hourly distribution of detections over the period. Not one of the twenty-four hours is empty — that is what makes continuous detection credible, rather than a claim.

hour of day · attacks detected

What we see coming through

Identified vectors, as a share of qualified attacks. Attacks whose vector could not be qualified are excluded from this calculation, and their number is stated.

  • udp 53,6 % 12 030
  • tcp_ack 17,2 % 3 866
  • tcp_syn 15,8 % 3 545
  • tcp_other 5,4 % 1 203
  • tcp_syn_ack 5,0 % 1 122
  • icmp 2,2 % 501
  • gre 0,5 % 117
  • tcp_rst 0,2 % 44

5 267 attacks whose vector was not qualified.

Notable attacks

The largest volumetrics of the period. No prefix, no address, no customer name: only the size of the targeted block is shown, because it carries technical meaning.

Detected Packet peak Bandwidth peak Vector Duration Target block State
2026-08-20 15:04 934 Mpps 598 Gbps unknown 485 min 52 s — Resolved
2026-08-23 10:00 905 Mpps 2.81 Tbps unknown 18 min 45 s — Resolved
2026-08-24 21:59 848 Mpps 542 Gbps unknown 695 min 39 s — Resolved
2026-08-24 21:59 816 Mpps 522 Gbps unknown 695 min 39 s — Resolved
2026-08-25 11:31 808 Mpps 517 Gbps unknown 545 min 38 s — Resolved
2026-08-25 11:31 776 Mpps 496 Gbps unknown 545 min 38 s — Resolved
2026-08-20 15:04 772 Mpps 494 Gbps unknown 485 min 52 s — Resolved
2026-08-20 12:00 678 Mpps 434 Gbps unknown 172 min 57 s — Resolved
2026-08-24 21:59 670 Mpps 429 Gbps unknown 695 min 39 s — Resolved
2026-08-24 06:15 555 Mpps 14 Mbps unknown 31 min 37 s — Resolved

Method and limits

What we count

An attack is an episode recorded by our filtering servers’ telemetry: detection timestamp, packets-per-second peak, bandwidth peak, vector where it can be qualified, and resolution timestamp. The peak reported is the maximum observed over the episode, not an average.

What we discard

Isolated outliers. A single reading more than three times above the 99.9th percentile is not treated as evidence until confirmed: it is more likely a measurement anomaly. One such reading exists in this period and does not appear in these figures.

What we do not publish

No prefix, no IP address, no customer or service identifier. The size of the targeted block is kept because it tells you about the nature of the attack without identifying anyone. No customer name will appear here without written permission.

The limits of this record

These figures describe what our servers saw and handled. They do not measure a false-positive rate, nor end-user perceived quality, nor a time to mitigate: the mitigation start time is only timestamped on a small share of episodes, so we do not publish it. We would rather say so than average a non-representative sample.