110 requests, 576.51ms median CPU time, something is going on,wo but what?

Hello, I recently got an email from Cloudflare (which shows me my worker summary report) when I opened that email, I noticed something very off! There were 110 requests and an average median CPU time of 576.51ms! So how the ■■■■ is this happening!? In addition, that SAME worker (which was giving me trouble yesterday) is unreachable with a 404 error! The link to that troublesome worker is https://www.talk-staind.submarine.workers.dev! Will somebody tell me why the median CPU time is so high and why it is returning a 404 error? Is the 404 error related to the high median CPU time? (which I suspect it is)!

What’s in the worker? What does it do?

1 Like

Are you using paid plan for Workers or not?
What does the Worker do?

No, I’m using a free plan

addEventListener("fetch", (event) => {
      (err) => new Response(err.stack, { status: 200 })

 * Many more examples available at:
 *   https://developers.cloudflare.com/workers/examples
 * @param {Request} request
 * @returns {Promise<Response>}
async function handleRequest(request) {
  const { pathname } = new URL(request.url);

  if (pathname.startsWith("/api")) {
    return new Response(JSON.stringify({ pathname }), {
      headers: { "Content-Type": "application/json" },

  if (pathname.startsWith("/status")) {
    const httpStatusCode = Number(pathname.split("/")[2]);

    return Number.isInteger(httpStatusCode)
      ? fetch("http://talkstaind.rf.gd/" + httpStatusCode)
      : new Response("Ok");

  return fetch("http://talkstaind.rf.gd/");

Fetches a website (which I am making changes to!)

Yeah, I see no issues with it, have you made a ticket with CF?

Not sure what’s happening with the URL though… doesn’t reflect what’s in the worker.

No, I haven’t

Tried publishing the worker again?

No, I’ll try that now

What hosting provider do you have? Make sure that they don’t block due to excessive requests from a single IP (Cloudflare worker).

It’s an infinityfree subdomain (the fetch URL)

Should I still try to “save and deploy” the worker to see if that fixes the issue?

@AppleSlayer, you do realise what you are doing here is essentially using Flexible, right?

Oh, son of a… I realize it! It’s using HTTP (which will trigger browser warnings if “Force secure connections” or smth like that) is on! I guess I should change the HTTP to HTTPS to fix the “using flexible” issue?

Sure, though https://talkstaind.rf.gd does not seem to work, which suggests the whole site is not configured for SSL.

This also suggests that

Well, I assume the whole thing is a playground for you. You are not going to hear me say now that it does not matter in that case :wink: but you get the point.

Just wanted to make you aware of the security issue :slight_smile:


And I think I just found the cause!

The certificate is self-signed (thus, untrusted)

And this

No certificate