Quick 3 questions 🥺 First, if a Bundled worker goes above their duration allotment, (10ms for free, 50ms for paid), what happens? Do they just get rejected and throw an error, does an 80ms duration count as 2 invocations (for paid)? Second, is network time being counted in the Pages > [Site] > Function Metrics > Median CPU Time? I have the follow SSR snippet (SvelteKit) and it says the average CPU time is about 13ms, which with network time sounds reasonable, without though is this just the time it's taking to SSR the whole page out and serve it?

ts
import type { PageServerLoad } from "./$types";

export const load = (async () => {
    const response = await fetch("https://catfact.ninja/fact");
    return await response.json();
}) satisfies PageServerLoad;

Third, I've seen a few people say network time isn't counted in Bundled Workers, but I can't seem to find this on the actual Docs, is this the case?

If it goes over, the worker will be killed with a resources exceeded error. If it says median CPU time, that should not include network time. 13ms doesn't sound that unreasonable to me, but I could be wrong. Yup. Bundled workers are charged based on CPU time, this does not include time your worker (or function) is waiting for the network.

That API seems to take about 125ms for me to return the response in the best cases, so I really think the 13ms is only CPU time.

Interesting, I'm on the free tier, is there any reason that this 12-16ms isn't throwing errors yet? And yeah that makes sense, I was getting about 40ms so I figured Cloudflares server may have just been VERY close if network time was being included. And I guess then regarding network time not being included, awesome!

If you just did

return fetch("https://catfact.ninja/fact")

instead of parsing the json on the server the cpu time should basically be 0ms since the cpu doesnt really do anything. Also the cpu time is very forgiving it will allow you to go over pretty frequently but you should aim to keep the average as low as possible.

You get rollover time and there is some grace.

If you have 10 requests that are 5ms and then 1 that is 30ms, that's going to be more acceptable than every request being 30ms off the bat

Yeah this is very true, json deserializing is a hell of a drug And I see, okay, yeah I'll mess around with it a bit and see if it's just that deserializing that is what's heavy here. Thank you all so much for the answers!!

Unfortunately there's no way to make a flame graph or profile a Worker due to timing constraints - but I don't think your example should take 13ms.

That's an extraordinarily simple workload - and there's very little to parse from that API.

Yeah, I did make another endpoint that generates some random numbers on the server and it takes about 1-2ms I'll mess with it though and see what it may be.

I'd imagine from the look of the code that is an SSR page from some framework so I'd imagine most of the cpu time is rendering that page

Perhaps, but even with the other page it's only a millisecond or two.

Probably just Svelte, yeah - https://community.cloudflare.com/t/simple-sveltekit-deploy-on-page-exceeds-cpu-because-one-server-side-call/474209

Well, that example is 3.3MB of JSON which is a pretty big issue

and I'm the one that replied to it

shoulda picked a better example

Perhaps it really just is the deserializing, without that it's about 3ms median

Hey guys! I have a Cloudflare Worker and a frontend. Currently, they live in two separate repos. The frontend deploys to Cloudflare Pages, as the repo is connected via the Cloudflare dashboard. The Worker is published via GitHub Actions. Now, I want to consolidate these two in the frontend repo. I moved the Worker's files to the /functions folder in the desired repo, but I don't see any changes via the Cloudflare dashboard (the functions list is empty). Could you please give me an idea of how to make this work?

Also I moved wrangler.toml to the root and adjusted path to my worker, but it didn't help

wrangler.toml

isn't considered by Functions

/functions

is for the path-based routing - i.e

/functions/hello.ts

would map to

example.com/hello

If you have an existing all-in-one Worker then you'd name it

_worker.js

and put it in the output directory

thank you so much @kian . Right now I have 4 files (index.ts, router.ts, context.ts and schema.ts). So I need to transpile those to a single _worker.js, right? I'll give it a go.

Pass

--bundle

to

wrangler pages publish

and you can just have an 'index'

_worker.js

that imports the rest as-needed if you want

otherwise yes, build them into a single

_worker.js

got it! Thank you once again @kian

Hey @kian Unfortunately, I encountered an error while trying to publish the function with the

_worker.js

file. The error message reads: "Error: Failed to publish your Function. Got error: multipart uploads must contain a readable body_part or main_module." Do you have any suggestions on how to resolve this issue? I'm using esbuild to bundle my worker like this

esbuild src/index.ts --bundle --outfile=_worker.js

how to access a secret in a function?

Through

env

e.g:

js
export function onRequest({ env }) {
  return new Response(env.SECRET);
}

Where the secret is literally called "SECRET"