CI Usage

Trylle meters each CI job by runner type and rounds its execution time up to a whole minute. Queue time is not billed as execution.

billed minutes = ceil(job runtime in seconds / 60)
cost = billed minutes * runner rate

Current runner rates

Check the pricing page before making long-term budget assumptions.

Jobs are metered separately

A workflow run is the container for its jobs, but metering happens per job. A four-way matrix whose jobs each run for 20 seconds bills four runner minutes, not one aggregate minute.

The same rule applies to small setup, report, or fan-out jobs. Combine very short jobs only when doing so also keeps the workflow understandable and preserves the desired failure boundaries.

Credits and wallet order

Eligible personal and organization plans receive monthly CI credit. When a job is admitted, Trylle consumes funds in this order:

1. CI category credit.
2. Eligible unrestricted promotional credit.
3. Prepaid wallet balance.

Free organizations do not receive monthly CI credit, but they can run CI after adding wallet funds. Plan credits reset on the UTC calendar-month boundary and do not roll over.

See Plans and usage for account ownership and credit rules, and CI usage and pricing for the billing-focused explanation.

Inspect repository usage

Use the CLI from any directory by specifying the repository:

try ci usage -R OWNER/NAME

The repository report summarizes measured runner seconds and bytes along with queued, running, succeeded, failed, skipped, and cancelled job counts for that repository identity. Use the repository and organization billing pages for wallet-level totals across several repositories.

Queueing and concurrency

Jobs wait until global, architecture, triggering-user, and organization capacity are available. Time spent queued does not count as runner execution time.

The service currently caps admitted work at 16 concurrent jobs per triggering user and 32 per organization, in addition to global and runner-pool limits. These values protect shared capacity and are not plan entitlements; they can change as capacity changes.

Use strategy.max-parallel to keep a large static matrix within the concurrency you actually need:

jobs:
  test:
    strategy:
      max-parallel: 4
      matrix:
        shard: [1, 2, 3, 4, 5, 6, 7, 8]
    runs-on: ubuntu-latest
    steps:
      - run: ./scripts/test-shard.sh "${{ matrix.shard }}"