Cloud Run Jobs take 90-120 seconds to start on us-central1, even with a minimal image.
I’ve so far used Cloud Run Services, also for jobs type tasks. They typically start in 2-3 seconds.
Now I tried switching over to Cloud Run Jobs and find it takes almost 2 minutes from creating the Job execution until the job actually starts running. Even for a hello world type job? Is this normal?
More detail: Cloud Run Jobs in us-central1 consistently take 90–120 seconds before the container actually begins producing stdout, even for a minimal prebuilt BusyBox image. The issue reproduces from both the Google Cloud Console and gcloud run jobs execute, so it is not related to Workflows. Provisioning appears quickly, but the execution does not actually start running until much later. We reproduced this with a minimal image to rule out Node, npm, application code, and source-based buildpacks.
It seems there is a huge queue delay in us-central1 for a month now. Looked it up, looks like everyone is using us-central1. I don’t have this problem since I deploy in eu-west1, but some of my cloud build is in us-central1 and even those are delayed (in a queue i guess). Maybe try switching to other regions, if you don’t care about which region your app is?
Hey, yeah this can feel super weird at first.
You’re basically seeing that Cloud Run Jobs behave very differently from Services—like services spin up fast, but jobs have that 1–2 min delay before execution actually starts. I faced something similar when I moved batch tasks to jobs and thought something was broken 
What worked for me:
-
Try switching region (I tested europe-west1 and got slightly better startup times)
-
Keep image super minimal and cached (sometimes cold pulls add delay)
-
For quick tasks, honestly I still stick to Cloud Run Services + HTTP trigger
Not sure if it helps but jobs seem optimized more for batch reliability than speed.
I even noted this in my Cookoutmenu dev notes while testing infra stuff.
Are you planning to fully switch to Jobs or just testing it out?