The Probes That Exposed a Hidden Cost in Our Website
on On September 20, a few thousand automated requests swept across BerylCode’s website in two brief bursts. Nine days later, similar probes returned across several of our public sites, and our Cloudflare Workers again began hitting CPU limits.
At first glance, this was the sort of background noise every public website attracts. But the requests were looking for unrelated secrets, debugging tools, and software we do not run. The pattern was unmistakably automated, and the Worker errors showed that the noise had a real operational cost.
The incident reports show no successful break-in, exposed credentials, or confirmed outage for visitors. They do show two separate occasions when Worker execution failed because requests exceeded CPU limits. Here is how we followed that trail, what we learned from the follow-up profiling, and how we have made the next investigation easier.
Two bursts, nine days apart
The first wave arrived on September 20. In a five-minute window from 12:01 to 12:06 UTC, Cloudflare recorded about 2,260 requests. Another 2,220 arrived between 12:30 and 12:34 UTC. Each burst was dominated by a single source, and the sampled paths jumped between PHP diagnostics, secret files, API keys, GraphQL, and debug endpoints.
The landing-page Worker recorded 4,200 invocations that day. It also recorded 492 errors, all attributed to exceeding CPU time limits. The error rate was 11.7%, and median CPU time was about 143 milliseconds. Cloudflare’s security rules stopped only a handful of requests in those two windows.
On September 29, the probes returned in a different shape. Instead of two short bursts, requests appeared across several hours and reached multiple public hostnames, including the US, LATAM, Requesto, and demo sites. Security Analytics counted 19,680 requests for the day; 407 were mitigated and 240 were reported as reaching the origin.
The Worker metrics told a parallel story: 7,290 invocations, 1,470 errors, and approximately 1,000 CPU-limit errors. The firewall records included blocks for React remote-code-execution and WordPress configuration-file probes. The same reliability warning appeared again, this time across more sites and over a longer period.
What the numbers can and cannot tell us
A Cloudflare Worker runs the code that serves a request. It has a CPU budget for that work. When execution exceeds the limit, the request can fail before the application finishes responding. That explains why a stream of invalid paths can matter even when no one is trying to use the site normally.
The September 29 Worker dashboard showed CPU percentiles ranging from about 74 milliseconds at the median to 443 milliseconds at P99. Those are observed measurements, not Cloudflare’s configured limit. September 20 also showed a high median, about 143 milliseconds, alongside the CPU-limit errors.
The edge analytics and Worker dashboards do not count the same thing. Edge analytics may sample incoming requests, while Worker metrics aggregate executions. A request shown at the edge does not automatically equal one Worker invocation, so adding or subtracting these totals would not reconcile the two data sets or create a reliable per-request count.
That is why we describe the two signals separately. The evidence strongly supports automated vulnerability scanning, and the Worker metrics confirm CPU-limit errors on both dates. The incident reports do not connect every sampled request to a particular Worker error, establish a confirmed DDoS motive, or show how many visitors were affected.
Following a bad request through the app
The obvious question was: which part of the website was doing so much work for a request that should end in a simple 404? The incident dashboards could not answer that. They recorded the failures, but did not include complete traces showing the path through application code for each failed request.
We used local profiles to follow sample requests through the site. One profile suggested that repeated metadata work could add cost when an unknown page is requested. It gives us a specific lead to investigate, but does not prove the production root cause.
The profile is a lead, not a verdict. It does not prove that metadata generation caused the production CPU spikes, or explain the hundreds of milliseconds recorded in Cloudflare. Local and production environments differ, and the local LATAM profile returned 404s with only about 7–8 milliseconds of sampled active time per request.
Later production log samples added another clue: some invalid routes used hundreds of milliseconds of CPU, but so did sampled requests to the home page. That tells us to profile both unknown paths and normal routes. We are tracing the whole request, rather than blaming one component before the evidence supports it.
What we changed
We added a Cloudflare security rule for paths that cannot be valid on BerylCode sites: secret files, WordPress configuration, PHP debugging, and similar probes. Those requests can now be stopped at the edge, before they reach the Worker and consume application resources.
We also enabled Worker observability for the US and LATAM sites. The logs capture the request path, method, status, outcome, and timing or CPU data when available. They avoid request bodies, secrets, and sensitive query values. That gives us a better chance of connecting a future error to the request and deployment that produced it.
We also checked host and port handling after seeing probes for an alternate address such as berylcode.com:8443. The tests confirmed that only intended hostnames reach application logic and that canonical redirects still behave as expected. The reports do not show that the alternate port caused the CPU failures, so we treated it as exposed surface to review rather than the root cause.
These changes address two different needs. Early filtering avoids needless work for requests that can never be legitimate. Better logs help us find the expensive path when a request still gets through. We also keep normal pages, search crawlers, contact forms, and APIs in the validation loop so that protection does not come at the cost of real visitors.
The work that continues
The September events were not evidence of a confirmed breach, but they were a useful resilience test. They showed that ordinary website traffic is not the only traffic worth designing for. A bot can turn an unremarkable 404 into a costly request if the route triggers enough shared application work.
We have a clearer map of the request path, a concrete metadata candidate to investigate, and better visibility on both production sites. We still need request-level production data to establish which code contributes most to CPU use and to measure whether the fixes keep invalid traffic within budget.
Our next step is to compare ordinary pages, expected 404s, and representative scanner paths under controlled conditions, then verify the results against production metrics. We will track CPU-limit errors and error rates alongside request volume, while treating sampled edge data as a signal rather than a complete record. Good incident response starts with evidence, and the evidence now available gives us a stronger way to act.
If you want a clearer view of your own website’s performance and the fixes that matter most, start with our 48-hour website audit. We’ll help you turn confusing symptoms into a prioritized, practical plan.