Resource class pinning for low-traffic workload cost reduction

Resource Pinning and Cost Impact

Explicitly pinning a resource_class in your .circleci/config.yml ensures that the executor size is locked regardless of project-level defaults. This directly controls the credit burn rate per minute for that specific job.

Interaction with auto_cancel

Explicit resource pinning does not change the logic of auto_cancel, but it reduces the financial impact of the time elapsed before termination. When auto_cancel triggers, CircleCI calculates costs based on the actual duration of resource usage up to the point of termination. Because a pinned smaller class (e.g., medium) has a lower credit cost per minute than a larger default, the "waste" incurred during the window between the start of a redundant job and its cancellation is minimized.

Handling Orb-defined Resource Classes

Orbs often encapsulate their own default resource_class within their internal commands. To ensure a job is not over-provisioned by an orb, you must explicitly define the resource_class at the job level in your configuration. Job-level definitions typically take precedence over the defaults bundled within orb commands.

Verification Steps

1. UI Validation: Navigate to the specific job run in the CircleCI dashboard. Inspect the Resource Class field in the job metadata to confirm the executor matches your pinned setting.
2. Billing Audit: Compare the credit consumption in your billing dashboard for a pinned job versus a default job of similar duration.
3. Cancellation Test: Trigger two concurrent runs with auto_cancel enabled. Verify in the job metadata that the terminated job's billed duration is limited to the time elapsed before the cancellation signal was processed.

Diagnostic Requirement

To provide a more precise cost-benefit analysis, please specify if you are using Linux or Windows executors, as the credit burn rates differ significantly between these environments.