8.4 Usage Limits, Billing Multipliers & Usage Metrics

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

---

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

[!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 \text{ min} \times 1 = 15 \text{ billable minutes}$
• Windows Job: $15 \text{ min} \times 2 = 30 \text{ billable minutes}$
• macOS Job: $15 \text{ min} \times 10 = 150 \text{ billable minutes}$
• Total Billable Minutes Deducted: $15 + 30 + 150 = 195 \text{ 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 \text{ min} \times 2 = 2 \text{ 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.