Service Update: Informed Clearly Mitigates DDoS Attack and Restores Availability

What happened

On 27 July 2026, Informed Clearly experienced a distributed denial-of-service (DDoS) attack that sent a sustained volume of automated requests to the website. The incident affected availability across our test, preproduction, and production services and temporarily caused HTTP 500 responses.

What we observed

At the busiest measured point before recovery, the reverse proxy handled 2,328 requests in a single minute. In a representative 60-minute window, two cloud-hosted /24 networks generated 47,762 of 63,728 requests—approximately 75% of all traffic. Of those requests, 44,361 were rejected POST requests to the CSP reporting endpoint.

After the two dominant networks were blocked, the traffic shifted to a more distributed crawl pattern. One five-minute sample contained 1,000 requests from 867 unique IP addresses, including 883 page-like GET requests. This confirmed that the incident involved rotating sources rather than a single address.

Impact and response

During the incident, an oversized Redis cache and exhausted host memory caused Redis to enter a restart loop, which produced the visible server errors. We blocked the two dominant network ranges at the router before connection tracking and the reverse proxy. By the final verification check, the router had dropped 57,706 packets from those ranges.

We preserved the previous Redis dataset as a rollback copy, purged the live cache, and restarted Redis with an empty dataset. Available host memory recovered from roughly 1.5 GB to more than 9 GB, and test, preproduction, production, the published incident page, and its images all returned HTTP 200 following recovery.

Current status

The outage caused by the concentrated attack has been averted and availability has been restored. Abusive automated traffic is still active and volatile. In the latest post-recovery sample, 1,000 requests arrived in 55 seconds from 268 unique IP addresses; 794 were CSP-report POST requests. The same sample contained no HTTP 500, 502, or 503 responses.

Active filtering and monitoring remain in place. We are also continuing work on earlier edge rate controls, stricter cache memory policies, and improved service-health monitoring. These changes are intended to reduce the impact of future traffic spikes and prevent an application cache from consuming all available host memory.

Transparency

The figures in this update come from the production reverse-proxy access log, MikroTik firewall counters, Docker container state, and public endpoint checks. The update may be revised if the continuing review identifies material new information.