Jobs start in seconds

Time to first job

The slowest part of many CI runs is not the tests. It is the wait before anything starts: the queue position, the runner that has to be provisioned, the image that has to be pulled. On Apex a job starts as soon as a runner is free. A machine that has just finished a job stays up for five minutes and takes the next one at once, in seconds. When none is free, one is started for the job, which takes about a minute. Capacity scales with your queue, up to your plan's concurrency (5, 20 or 50 jobs at once).

Bigger machines when you want them

A larger runner is a label, not an add-on. Change one line in a job — runs-on: apex-4core-x64 — and it runs on 4 cores and 16 GB, the same architecture as ubuntu-latest. apex-4core is the arm64 equivalent. A larger runner has no separate price; a minute on it counts as two standard minutes.

jobs:
  test:
    runs-on: apex-4core-x64   # the only line that changed
    steps:
      - uses: actions/checkout@v4
      - run: pnpm test

The parts of a run that are slow are named

Every step in every job carries a timing, and each run is compared against its own history for that workflow and that matrix leg. When a step is slower than it usually is, the run says so — you do not read a log looking for the gap.