Cloud Run Job
Does ZopNight manage Cloud Run Job?
Cloud Run jobs bill CPU and memory only for the seconds each execution runs, so an idle job costs 0. ZopNight inventories jobs through Cloud Asset Inventory and attributes execution spend from the billing export, catching retried, oversized, and forgotten scheduled executions that still burn compute without any standing service.
Rules that fire on Cloud Run Job
No active rule family targets Cloud Run Job today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
Cloud Run jobs execute containers to completion for batch-style work, billed only for the duration of each execution. They carry no standing cost, but failed or oversized executions still waste compute.
Cost proportional to execution seconds
A Cloud Run job charges vCPU-seconds and GiB-seconds of memory for exactly as long as its tasks run, multiplied by task count and parallelism. Between executions the job definition sits in the project as free configuration. That makes jobs one of the cleanest billing models on GCP. It also means every wasted dollar traces back to an execution that ran longer, wider, or more often than the work required.
Attributing batch spend to its source
ZopDev inventories Cloud Run jobs via Cloud Asset Inventory and attributes their execution spend from billing export actuals. Because there is no idle cost to schedule away, jobs sit outside ZopNight’s stop/start machinery entirely; the value is visibility. Batch spend otherwise hides inside a project’s aggregate serverless line, and mapping it back to a named job is what turns “our Cloud Run bill grew” into “the nightly export job doubled its runtime in March.”
How run-to-completion work overspends
The first pattern is the forgotten trigger: a Cloud Scheduler entry faithfully launching a job whose consumers disappeared a quarter ago. The second is failure loops: executions that crash late, retry, and pay for every doomed attempt, where the meter records the full task duration up to each failure. The third is over-allocation: task CPU and memory sized for a worst case that never arrives, inflating the per-second rate of every execution. A job with high parallelism compounds all three, since each setting multiplies across simultaneous tasks.
Execution history in the console
Google Cloud console → Cloud Run → Jobs lists each job with its last execution result. Opening a job shows its execution history (durations, task counts, and failures), which is the fastest manual check on whether a batch workload is doing useful work or expensively spinning.