Study guide
8.4 Usage Limits, Billing Multipliers & Usage Metrics
GitHub Actions Certification GH-200
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Introduction & Exam Overview
1.1 Exam Structure, Format & Scoring 1.2 GitHub Actions Architecture & Core Mental Model 1.3 Hands-On Preparation & Exam Day Strategy
2 Chapter 2: Workflow Triggers & Event Architecture
2.1 Webhook & Code Events: push, pull_request, and pull_request_target 2.2 Scheduled & Manual Triggers: schedule, workflow_dispatch, and repository_dispatch 2.3 Release, Issue, and Dynamic Lifecycle Events 2.4 Branch, Tag, and Path Filtering Patterns
3 Chapter 3: Jobs, Matrix Strategies & Execution Control
3.1 Job Anatomy, Step Execution & Job Dependencies (needs) 3.2 Contexts, Expressions & Functions 3.3 Environment Variables & Workflow Commands 3.4 Matrix Strategies & Multi-Platform Builds 3.5 YAML Anchors, Aliases & Merge Keys
4 Chapter 4: Reusable Workflows & Troubleshooting
4.1 Authoring & Calling Reusable Workflows (workflow_call) 4.2 Comparing Reusable Workflows, Composite Actions & Starter Workflows 4.3 Troubleshooting Workflow Runs & Debug Logging 4.4 Concurrency Controls & Status Check Functions
5 Chapter 5: Authoring Custom Actions
5.1 Action Architecture & action.yml Specification 5.2 Authoring Composite Actions 5.3 Building JavaScript Actions 5.4 Building Docker Container Actions
6 Chapter 6: Action Distribution, Marketplace & Advanced Action Types
6.1 Action Versioning, Semantic Releases & Tagging 6.2 Publishing Actions to GitHub Marketplace 6.3 Service Containers & Network Topology 6.4 actions/github-script & Workflow Tooling
7 Chapter 7: Runner Infrastructure & Self-Hosted Runners
7.1 GitHub-Hosted Runners & Larger Runners 7.2 Self-Hosted Runner Setup, Architecture & Communication 7.3 Self-Hosted Runner Security & Ephemeral Runners 7.4 Runner Groups, Labels & Organization Routing
8 Chapter 8: Enterprise Governance, Policies & Environments
8.1 Enterprise & Organization Action Policies 8.2 Environments, Protection Rules & Deployment Approvals 8.3 Repository Rulesets, Required Status Checks & Governance 8.4 Usage Limits, Billing Multipliers & Usage Metrics
9 Chapter 9: Secrets, Permissions & OIDC Cloud Authentication
9.1 Encrypted Secrets Architecture & Scopes 9.2 GITHUB_TOKEN & Least Privilege Configuration 9.3 OpenID Connect (OIDC) & Workload Identity Federation 9.4 Script Injection Prevention & Secure Workflow Patterns
10 Chapter 10: Supply Chain Hardening & Performance Optimization
10.1 Supply Chain Hardening: SHA Pinning, Dependabot & Artifact Attestations 10.2 Caching Dependencies with `actions/cache` 10.3 Artifacts Management & Job Handoff 10.4 Workflow Performance, Cost Optimization & Architecture Review
8.4 Usage Limits, Billing Multipliers & Usage Metrics
Key Takeaways Explain This Topic AI
Job execution limits differ by runner type: 6 hours on GitHub-hosted runners, 5 days on self-hosted runners, plus a 24-hour queue limit before a self-hosted job is cancelled.
A whole workflow run - including wait timers and approval queues - is cancelled at 35 days, and a run may wait no more than 30 days on an environment approval gate.
Included-minute consumption is weighted by operating system: Linux counts 1x, Windows 2x, and macOS 10x, with each job's duration rounded up to the next whole minute.
Standard-runner job concurrency is set by plan: 20 on Free, 40 on Pro, 60 on Team, and 500 on Enterprise, with tighter macOS sub-limits and a separate 1,000-job ceiling for larger runners.
Actions consumption is audited through the billing CSV export or the billing REST API, and capped in advance with a spending limit that defaults to $0 for private repositories.
Last updated: August 2026
Usage Limits, Billing Multipliers & Usage Metrics
Operating GitHub Actions at enterprise scale requires a clear understanding of system execution boundaries, concurrency limits, and compute consumption economics.
GitHub-hosted runners consume billable minutes that are weighted according to runner operating systems and compute architectures. Mastering usage limits, OS billing multipliers, spending guardrails, and programmatic billing metrics is a foundational requirement for the GitHub Actions Certification (GH-200) exam.
1. System Execution Boundaries & Hard Limits
GitHub Actions enforces predefined architectural limits to ensure platform stability and prevent runaway compute consumption.
Hard Quotas & Limits Cheatsheet
Limit Category Threshold / Boundary Operational Impact & Behavior
Job execution (GitHub-hosted) 6 hours (360 minutes) A job on a GitHub-hosted runner is terminated once it exceeds 6 hours. Configurable downwards with timeout-minutes . ubuntu-slim single-CPU runners cap at 15 minutes instead.
Job execution (self-hosted) 5 days A job on a self-hosted runner may run far longer than a hosted one - the 6-hour ceiling does not apply.
Job queue time (self-hosted) 24 hours A job waiting for a self-hosted runner is cancelled automatically after 24 hours if no runner picks it up.
Workflow run time 35 days A run - including all jobs, wait timers, approval queues, and retries - is cancelled after 35 days.
Gate approval time 30 days A run may wait at most 30 days on an environment approval before it is terminated.
Matrix generations 256 jobs / run A strategy.matrix cannot generate more than 256 jobs per workflow run, on hosted or self-hosted runners.
Workflow file size 500 KB per file A workflow file larger than 500 KB will not start runs. Move shared logic into a reusable workflow or composite action.
Workflow re-runs 50 re-runs A run can be re-run at most 50 times, counting both full re-runs and partial job re-runs.
API rate limits 1,000 requests/hr per repository; 15,000 requests/hr (Enterprise Cloud) Calls authenticated with GITHUB_TOKEN share a per-repository hourly budget.
Artifact & log retention Default 90 days Configurable 1-90 days in public repositories and 1-400 days in private and internal repositories.
2. Concurrency Limits by Account Tier
GitHub-hosted runner execution is subject to concurrent job capacity limits determined by the account plan: Account Plan Concurrency Limits:
- ┌─────────────────────────────────────────────────────────────┐
- │ Free: 20 total concurrent jobs (max 5 macOS) │
- ├─────────────────────────────────────────────────────────────┤
- │ Pro: 40 total concurrent jobs (max 5 macOS) │
- ├─────────────────────────────────────────────────────────────┤
- │ Team: 60 total concurrent jobs (max 5 macOS) │
- ├─────────────────────────────────────────────────────────────┤
- │ Enterprise: 500 total concurrent jobs (max 50 macOS) │
- ├─────────────────────────────────────────────────────────────┤
- │ Larger runners (Team/Enterprise): 1,000 concurrent jobs │
- │ (max 100 GPU jobs) │
- └─────────────────────────────────────────────────────────────┘
Note
macOS is the tightest constraint. The macOS sub-limit sits inside the overall figure: a Team account can run 60 concurrent jobs but no more than 5 of them on macOS. A large iOS build matrix therefore serializes long before the account-wide ceiling is reached. GitHub Support can raise job concurrency limits on request.
Queuing Behavior
When an organization triggers more jobs than its plan concurrency threshold allows, excess jobs are placed into a queued state. As active jobs finish and release runner slots, queued jobs transition to in_progress according to priority and queue time.
Note
Public vs. Private Repositories: GitHub Actions is completely free for standard GitHub-hosted runners in public repositories. Monthly included minutes and per-minute billing apply strictly to private and internal repositories .
3. OS Billing Multipliers & Calculation Mechanics
Execution time on GitHub-hosted runners is billed in whole minutes. If a job executes for 1 minute and 12 seconds, GitHub rounds up the execution duration to 2 whole minutes before applying the operating system multiplier.
Operating System Multiplier Table
- Runner operating system Hardware Minute multiplier (included minutes) Published per-minute rate (USD)
- Linux (Ubuntu) Standard 2-core 1x $0.006 / min
- Windows Server Standard 2-core 2x $0.010 / min
- macOS Standard 3-core or 4-core 10x $0.062 / min
- macOS larger runner 12-core n/a - billed per minute $0.077 / min
- macOS larger runner 5-core (M2 Pro) n/a - billed per minute $0.102 / min
- Self-hosted runners Customer-managed compute 0x (free) $0.000 / min
Important
Multipliers and dollar rates are two different systems - do not conflate them. The 1x / 2x / 10x multipliers govern how fast a job burns the included minutes bundled with your plan. Once those are exhausted, GitHub bills the published per-minute rate for that machine size, which is not simply the Linux rate times the multiplier. Larger runners are always billed per minute and never consume included minutes.
- Worked Billing Calculation Examples
- Example 1: Multi-Platform Matrix Run
Suppose a workflow runs a multi-platform build matrix across Linux, Windows, and macOS standard runners in a private repository. Each job runs for exactly 15 minutes :
Linux Job: 15 min × 1 = 15 billable minutes 15 \text{ min} \times 1 = 15 \text{ billable minutes} 15 min × 1 = 15 billable minutes
Windows Job: 15 min × 2 = 30 billable minutes 15 \text{ min} \times 2 = 30 \text{ billable minutes} 15 min × 2 = 30 billable minutes
macOS Job: 15 min × 10 = 150 billable minutes 15 \text{ min} \times 10 = 150 \text{ billable minutes} 15 min × 10 = 150 billable minutes
Total Billable Minutes Deducted: 15 + 30 + 150 = 195 minutes 15 + 30 + 150 = 195 \text{ minutes} 15 + 30 + 150 = 195 minutes
Example 2: Partial Minute Rounding Impact
Suppose an automated linter job runs on Windows for 45 seconds :
Execution time of 45 seconds rounds up to 1 minute .
Windows multiplier of 2x is applied: 1 min × 2 = 2 billable minutes 1 \text{ min} \times 2 = 2 \text{ billable minutes} 1 min × 2 = 2 billable minutes .
4. Spending Limits & Cost Controls
To prevent unexpected cloud billing overages, GitHub accounts default to a Spending Limit of $0 , which stops workflow execution in private repositories once included monthly minutes are exhausted.
Managing Spending Limits
Administrators can configure a custom spending limit (e.g., $500/month) under Billing & Plans → Spending limits .
Email Threshold Alerts: GitHub notifies organization owners as consumption approaches and reaches the configured spending limit, so finance owners are warned before jobs stop rather than after.
When the spending limit is reached ($100%), all Actions jobs in private repositories are paused or rejected until the limit is raised or the next billing cycle begins.
5. Monitoring Usage & Reporting Tools
Enterprise platform teams have two primary methods for monitoring and analyzing Actions consumption:
1. Granular Usage Report (CSV Export)
Administrators can download a detailed CSV report from Settings → Billing → Get usage report . The CSV includes line-by-line records with fields:
- Date : Timestamp of execution
- Product : Actions
- SKU : Compute - Ubuntu , Compute - Windows , or Compute - macOS
- Quantity : Number of billable minutes
- Unit Type : Minutes
- Price Per Unit : Unit rate applied
- Total : Total cost incurred
- Owner & Repository Slug : Specific repository responsible for the cost
- Workflow Name : Name of the triggering workflow file
- 2. GitHub REST API Billing Endpoints
Enterprises can programmatically query Actions consumption for real-time FinOps dashboards using the REST API: GET /orgs/{org}/settings/billing/actions
- Host: api.github.com
- Authorization: Bearer <ADMIN_TOKEN>
- Accept: application/vnd.github+json
- Example JSON Response: {
- "total_minutes_used": 42500,
- "total_paid_minutes_used": 12500,
- "included_minutes": 30000,
- "minutes_used_breakdown": {
- "UBUNTU": 22500,
- "WINDOWS": 10000,
- "MACOS": 10000
- }
- }
Enterprise administrators can also query enterprise-level billing via GET /enterprises/{enterprise}/settings/billing/actions to monitor usage across all organizational units.