Cloud Run Jobs: a thumbnail factory with a one-minute meter

A video catalogue needs preview images. There are 1,000 short clips, each about a minute long, and the publishing team wants a small contact sheet's worth of frames from each. The work can run after the uploads finish. Keeping a web server available all day would solve a different problem.

Google Cloud Run Jobs is a concrete option: package the extraction code in a container, divide the catalogue into tasks, run them, and exit. Google distinguishes jobs from request-serving Cloud Run services; a job can contain up to 10,000 independent tasks, with the application responsible for distributing the records. S1

The useful buying question is surprisingly small: should one clip equal one task? For this workload, the billing minimum makes that decision worth examining before choosing a larger machine.

Build a thumbnail factory

PCT's proposed job uses FFmpeg on a CPU. For every five seconds of video, it produces one JPEG, resized to 320 pixels wide with proportional height. Google publishes its own Cloud Run video-transcoding tutorial using GPUs; this example deliberately asks a smaller question about CPU thumbnail extraction rather than assuming a GPU is necessary. S6

Start with a fixed manifest of input objects, including each object's generation number. That identifies the specific stored version to process. The example accepts clips between five and sixty seconds and no larger than 50 MiB. Those are protective limits chosen for this recipe, not Cloud Run product limits.

The worker downloads one clip, runs the extraction, puts the images into one archive, uploads the completed archive, and moves to the next clip. One clip at a time keeps temporary files from accumulating. A representative command is:

`ffmpeg -i input.mp4 -map 0:v:0 -vf "fps=1/5,scale=320:-2" -an frame-%04d.jpg`

The accompanying Python worker adds size checks, error handling and upload preconditions. A local smoke test produced twelve 320-by-180 JPEGs from a synthetic sixty-second video. That verifies a basic output path. The container has not been built or run in Google Cloud, and the smoke test establishes no cloud throughput or cost benchmark.

The minute that changes the arithmetic

For regular jobs in Iowa, us-central1, Google's price page lists $0.000018 per vCPU-second and $0.000002 per GiB-second. Jobs pay for an instance's lifetime, with a one-minute minimum for each started instance. The price snapshot here is November 7, 2026. It excludes delayed-job rates and commitment discounts. S2

Consider a deliberately explicit planning case. Every task has one vCPU and one GiB of memory. Assume each clip takes twenty seconds for download, processing and upload, plus five seconds of container overhead per task. Assume no failures, retries, sidecars or overlapping executions. These times are modeling assumptions, not observed FFmpeg performance.

The combined compute rate is $0.000020 per instance-second. Give each clip its own task and its assumed twenty-five-second lifetime is billed as sixty seconds. Across 1,000 tasks, that is 60,000 billed seconds and $1.20 of gross compute.

Now put twenty clips into each of fifty tasks. Each instance lives for an assumed 405 seconds: twenty times twenty, plus five. Total billed time becomes 20,250 seconds, costing $0.405 of gross compute. The model saves 79.5 cents, or about 66%, without changing the machine size or the amount of useful extraction work.

These are compute subtotals before free allowances, taxes, storage, object operations, image builds, registry charges, logging and applicable network charges. Google's free tier is shared across projects under a billing account, so an isolated demonstration may have no incremental Cloud Run compute charge at all. S2 A small example should not be sold as a production invoice.

Make the bundle a recoverable unit

Grouping records also enlarges the unit that can fail. If clip nineteen is corrupt, restarting an entire twenty-clip bundle wastes work unless the application remembers the eighteen completed results. Google's guidance recommends idempotent jobs and preserving output separately from input. S3

Our recipe names each output using the input's bucket, object name, generation and recipe version. It uploads one completed archive per clip, then checks for that archive on a retry. A generation-match precondition of zero permits creation only when there is no live object at the destination name. S5 That protects against competing attempts overwriting the same result.

The important distinction is between retrying a container and accepting its outputs. A permanent decoding failure still needs an error record and an operator decision. The minimal recipe fails the task; a production pipeline should quarantine the bad clip and reconcile the full manifest against accepted archives. Otherwise later clips in the same bundle can remain unattempted.

Cloud Run's normal writable filesystem is memory-backed and disappears when the instance stops. S4 A fifty-megabyte source file is therefore part of the memory budget, alongside the decoder, Python process and output images. One GiB is a trial configuration, not a promise that every codec or high-resolution input will fit.

A small run before the large run

The supplied recipe includes a Dockerfile, a manifest generator and a worker. It assumes existing authorized buckets, an image repository and a service account with the required access.

For the 1,000-record case, fifty tasks produce twenty records per task. Set parallelism to ten to cap concurrent task instances. That setting controls how many bundles run together, not how many records belong in each bundle. Cloud Run exposes the task index and task count to the container so the worker can make the assignment. S1

Start with a smaller representative manifest. Check image quality, peak memory, complete output coverage, retries and actual billed instance time. Then compare one-clip tasks with bundled tasks using the same inputs and acceptance checks. Long or difficult clips can make equal-sized bundles finish unevenly; a record count alone is a poor estimate of processing effort.

What the buyer actually learns

The saving in this example is less than a dollar per run. That is an argument for a simple implementation, not a new scheduling platform. At larger volume, the same minimum-charge effect can become material. At smaller volume, maintainability and correct outputs deserve more attention than the third decimal place on the CPU tariff.

PCT's interpretation is that the unit of work belongs in a compute-price comparison. An attractive per-second price does not fully describe a service when every instance carries a minimum bill. Cloud Run Jobs earns a place on the shortlist when independent, containerized work can finish and release its resources. Whether it wins this catalogue depends on measured runtime, failure behavior and the full bill, not the illustrative saving above.