GitHub Actions and Sustainability

A practical guide to what GitHub's API provides (and doesn't provide) for carbon-aware computing, with actionable recommendations for time and region shifting.

Back to Home

Overview

This document addresses a common question: Does GitHub’s API provide sustainability information that could be used to define better times to compute?

Short answer: No, GitHub’s public API does not currently expose carbon intensity, energy mix, datacenter location, or real-time grid data for hosted runners.

What GitHub’s API provides

Available through GitHub Actions API

The GitHub Actions REST API provides:

  • Workflow run status and logs
  • Job execution times and outcomes
  • Runner usage statistics (minutes consumed)
  • Artifact management
  • Self-hosted runner registration and management

Not available through GitHub’s API

The following sustainability-related data is not exposed via GitHub’s public API:

  • Physical datacenter location for hosted runners
  • Real-time carbon intensity of the grid powering the runner
  • Energy mix (renewable vs. fossil fuel) for specific workflow runs
  • Per-job energy consumption or carbon emissions estimates
  • Regional availability or ability to select specific Azure regions for hosted runners

GitHub-hosted runner infrastructure

Current constraints

  1. Hosting platform: GitHub-hosted runners run on Microsoft Azure virtual machines
  2. Region control: Users cannot select or pin specific Azure regions for standard hosted runners
  3. Datacenter opacity: The exact physical location of runners is not exposed or guaranteed
  4. No real-time energy signals: GitHub does not provide APIs to query grid carbon intensity or renewable energy percentage at run time

Source: About GitHub-hosted runners

What this means for time and region shifting

For hosted runners:

  • ❌ Region shifting is not possible with standard hosted runners (you cannot choose or switch regions)
  • ❌ Real-time grid-aware scheduling is not supported (no API access to carbon intensity data)
  • ⚠️ Time shifting is partially possible (you can defer non-urgent jobs, but you don’t know the carbon impact of the shift)

For self-hosted runners:

  • ✅ Region shifting is possible (you control where runners are deployed)
  • ✅ Time shifting is possible (you can integrate with carbon intensity APIs)
  • ✅ Full control over infrastructure and energy-aware scheduling decisions

Microsoft’s sustainability tools

While GitHub’s API doesn’t provide job-level sustainability data, Microsoft offers some related tools:

Emissions Impact Dashboard

Microsoft provides Emissions Impact Dashboard for:

  • Azure cloud resource consumption estimates
  • Microsoft 365 usage carbon footprint
  • Organization-level reporting

Limitations for GitHub Actions:

  • Not granular to individual workflow runs or jobs
  • Not accessible via API for real-time decision-making
  • Requires enterprise-level Azure or M365 subscriptions

Practical recommendations

1. Use self-hosted runners for carbon-aware workloads

If region and time shifting are priorities:

jobs:
  carbon-aware-build:
    runs-on: self-hosted
    # Deploy your self-hosted runner in a low-carbon region
    # Integrate with carbon intensity APIs before triggering

Implementation steps:

  1. Deploy self-hosted runners in regions with cleaner energy grids
  2. Use Electricity Maps API or Grid Intensity CLI to check current carbon intensity
  3. Schedule deferrable jobs during low-carbon windows
  4. Set maximum delay bounds to protect delivery commitments

2. Time-shift deferrable workloads

For non-urgent jobs (nightly builds, batch processing, reports):

on:
  schedule:
    # Run during typical low-demand hours
    # (actual carbon impact depends on grid and location)
    - cron: '0 2 * * *'  # 2 AM UTC

Limitations:

  • You won’t know the actual carbon intensity without external data
  • GitHub-hosted runners may run in different datacenters even at the same time
  • This is a best-effort approach without real-time carbon feedback

3. Minimize compute overhead

Focus on what you can control directly:

  • Reduce job runtime: Faster jobs consume less energy
  • Use caching aggressively: Avoid redundant computation
  • Right-size runner resources: Don’t over-provision
  • Remove unused workflows: Dead code still consumes CI minutes
  • Use incremental builds: Only rebuild what changed

4. Monitor and measure

Track metrics you can influence:

# Example: Track CI minutes per month
# Report in your SUSTAINABILITY.md metrics table

Key metrics:

  • Total Actions minutes consumed per month
  • Average job duration trends
  • Cache hit rates
  • Failed job retry overhead

Alternative approaches

Carbon-aware workflow control (experimental)

You could implement external carbon-aware gating:

jobs:
  check-carbon-intensity:
    runs-on: ubuntu-latest
    outputs:
      should-run: $
    steps:
      - name: Check carbon intensity
        id: carbon-check
        run: |
          # Call external carbon API
          # Return 'true' if intensity is below threshold
          echo "run=true" >> $GITHUB_OUTPUT

  heavy-job:
    needs: check-carbon-intensity
    if: needs.check-carbon-intensity.outputs.should-run == 'true'
    runs-on: ubuntu-latest
    steps:
      - name: Run heavy computation
        run: npm run build

Trade-offs:

  • Adds complexity and a dependency on external APIs
  • The check job itself consumes compute
  • Still doesn’t solve the region selection problem
  • May delay delivery unpredictably

Future possibilities

What would help from GitHub

The sustainability community would benefit if GitHub provided:

  1. Runner location transparency: Expose which Azure region a job ran in
  2. Carbon intensity API: Real-time or historical carbon data per runner
  3. Region selection: Allow users to prefer or pin regions for hosted runners (especially for larger runners)
  4. Energy consumption metrics: Per-job energy use estimates in Actions telemetry
  5. Green runner pools: Pre-configured runner groups in regions with cleaner grids

Advocacy and feedback

If these capabilities are important to you:

  • Submit feedback via GitHub Community Discussions
  • Mention sustainability as a use case in feature requests
  • Share this document and use cases with GitHub support

Summary

Capability GitHub-hosted runners Self-hosted runners
Region selection ❌ Not available ✅ Full control
Carbon intensity API ❌ Not available ✅ Via external APIs
Time shifting ⚠️ Partial (no feedback) ✅ With carbon awareness
Energy consumption data ❌ Not available ⚠️ Requires custom tooling

Bottom line: For sustainability-aware compute scheduling, self-hosted runners with external carbon intensity APIs are currently the only practical option. GitHub-hosted runners do not expose the data needed for informed region or time-shifting decisions.

Last updated: 2026-02-22
Status: Current as of GitHub Actions API and documentation review