Summary

  • GitHub rounds each job’s minutes and partial minutes upwards separately. Adding all the seconds first and rounding once can hide the price of splitting the work.
  • Six complete ten-second jobs produce six billed minutes; one complete sixty-second job produces one. At the current standard two-core x64 Linux rate, those scenarios consume $0.036 and $0.006 of compute value respectively.

A small job can travel in an expensive amount of packaging. GitHub Actions supplies each one with a whole-minute billing unit. Split sixty seconds of total execution into six ten-second jobs and the meter can sell six minutes without finding another second of work.

The rule sits at the top of the official runner price table: each job’s minutes and partial minutes are rounded upwards to a whole minute. The rate per minute is only half the purchasing decision. The other half is how many separately rounded clocks the workflow creates.

Six small parcels, six full boxes

Fix a private repository and the same standard two-core x64 Linux runner. Its current listed rate is $0.006 per minute. Assume six complete jobs, each with exactly ten seconds of measured job execution time. Each rounds to a minute: six minutes, consuming $0.036.

One complete job with exactly sixty seconds of execution stays at one minute and $0.006. Both scenarios contain sixty summed runner-seconds. The difference in gross compute value is $0.03. These are assumed durations put through the published rule. Combining actual work can change preparation, cleanup, dependencies and total execution time; the comparison supplies a price mechanism rather than a measured redesign result.

The word “complete” earns its keep. A ten-second command does not establish a ten-second job. The job execution-time view is the starting point for duration and billable minutes. Runner class, current rate and the financial usage report complete the calculation.

A second with unusually strong purchasing power

A sixty-one-second job rounds to two minutes. A sixty-second job stays at one. Saving a second across that boundary halves the billed quantity. Saving a second from eleven to ten leaves one billed minute in both cases.

The price has steps. Saved seconds and saved money do not march in a fixed ratio. A modest improvement near a minute boundary can reduce more billed quantity than a large improvement to a job already comfortably below it. A league table of seconds saved could award the budget prize to the wrong optimisation.

There is a third clock: how long a developer waits for an answer. Parallel jobs can shorten that wait while their summed runner time remains a separate quantity. Individual rounding adds another measure again. Time to result, total machine execution and billed minutes belong in separate columns. A faster green tick can be worth buying; its speed alone does not explain its price.

Included value pays before additional cash does

The current billing explanation expresses a plan’s included compute usage as money. Eligible runner usage, cloud sandbox compute and memory can draw from the same included value, with no eligible usage type taking priority. The amount resets at the start of a billing cycle. Additional usage is charged after that value is consumed.

The scenario’s $0.036 can therefore spend down included value first. Beyond the allowance, it becomes additional cash. Before that point it occupies value another eligible workload could have used. Waiting for the first extra card charge would leave part of the buying decision off the page.

Standard GitHub-hosted runners remain independently free for public repositories. Larger runners are billed for public repositories too. The numerical comparison deliberately fixes a private repository and one standard class. Mixing those categories would spoil the price comparison before the stopwatch started.

Some boundaries earn their packaging

The Actions component guide distinguishes workflows, jobs and steps. A job’s steps use the same runner; separate jobs have their own execution environments. Jobs without dependencies run in parallel by default. Current features also allow selected steps to run concurrently within a job, so parallelism does not invariably require more job boundaries.

Different operating-system tests, separated environments, clearer failure separation and early feedback can justify buying those boundaries. Sharing a runner also permits data to pass between steps. Removing a required test or combining work that needs distinct trust and permission boundaries would change the product being bought to obtain a cheaper rounding result.

A real saving requires actual whole-job durations, runner classes, equivalent check results, time to result, reruns and included-value consumption. The payer is already identifiable: the repository owner, rather than the person triggering the workflow. The people dividing the work are choosing purchasing units for that owner’s budget. A ten-second job can be an excellent idea. Its full minute should be able to explain what the extra boundary delivered.