---
title: Carbon-Aware Workflow Execution
url: https://www.emergentmind.com/topics/carbon-aware-workflow-execution
type: topic
---

# Carbon-Aware Workflow Execution

Carbon-aware workflow execution is the scheduling and control of computational workflows so that their electricity use is aligned with lower-carbon conditions in time, place, and execution mode. In current research, the concept encompasses delaying temporally flexible workloads to “greener” hours, shifting execution across regions, pausing and resuming interruptible workflows, adapting worker intensity or cluster capacity, and selecting alternative resources or implementations, while preserving deadlines, precedence constraints, service-level objectives, or quality thresholds. The workload classes studied include recurrent industrial analytics, datacenter batch workloads, DAG-based data processing, scientific workflows, CI/CD pipelines, serverless functions, and edge function-calling systems [2605.24561] [2106.11750] [2502.09717] [2508.14625].

## 1. Workload characteristics and scope

Carbon-aware execution is motivated by the fact that many important workflows are large, repeated, and operationally persistent rather than one-off. In recurrent industrial analytics, representative examples include parametric database generation, periodic retraining, validation campaigns, hyperparameter search, and repeated model evaluation. The central concern is cumulative operational burden: even moderate per-run energy cost becomes substantial when refresh cycles recur. CARINA frames these workloads as schedulable, measurable, and optimizable systems rather than static code that merely runs to completion [2605.24561].

The degree of achievable carbon awareness depends on workload flexibility. In datacenter settings, carbon-aware scheduling is typically restricted to delay-tolerant computation; user-facing and latency-sensitive services are not shifted, but lower-tier, batch, AI training, data processing, and offline video processing jobs can be delayed. Carbon Explorer cites Google Borg traces as showing about **40% of jobs** are flexible enough to have 24-hour completion SLOs, and describes Meta’s data processing workloads as about **7.5% of all workloads**, with **87.4%** of those having SLOs greater than 4 hours and a majority with **24-hour SLOs** [2201.10036].

Scientific workflows have been highlighted as especially promising because they are often significantly delay tolerant, efficiently interruptible, highly scalable, and widely heterogeneous. Studies centered on Nextflow workflows argue that persisted intermediate data and task-level DAG structure make workflow-level pausing and resumption practical, while heterogeneous task resource profiles create opportunities for temporal shifting and resource scaling [2503.13705]. A closely related argument appears in CI/CD research, where periodic jobs such as nightly builds and scheduled test pipelines, and multi-step workflows with interdependencies, are treated as especially promising targets for carbon-aware orchestration, albeit under the constraint that fast feedback remains central to CI/CD practice [2310.18718].

## 2. Carbon accounting and objective functions

A common modeling choice is to treat energy as the primary operational quantity and derive emissions from energy using a carbon-intensity signal. CARINA states the relationship explicitly as
$$
\text{CO}_2\text{e} = E \times g
$$
where \(E\) is estimated energy consumption and \(g\) is the local grid emission factor. In the same spirit, CarbonCall defines operational carbon footprint as
$$
CF = E \times CI
$$
with \(CI\) the carbon intensity of electricity [2605.24561] [2504.20348].

Several papers decompose total footprint into operational and embodied terms. The CI/CD ecosystem study uses
$$
\text{Carbon Footprint} = \text{Operational Emissions} + \text{Embodied Emissions},
$$
while CarbonSim adopts a lifecycle formulation,
$$
\text{tot\_emissions} = \sum_{t=1}^{T} \left( op\_emissions_t(s) + embodied\_emissions_t(s) \right).
$$
This distinction is consequential: operational emissions depend on runtime energy and the carbon intensity of electricity, whereas embodied emissions depend on hardware manufacture, deployment, and lifetime attribution [2510.26413] [2606.06438].

The carbon-intensity signal itself is not uniform across the literature. Scientific workflow studies explicitly compare **average CI** and **marginal CI**, using **Electricity Maps** for average CI at hourly granularity and **WattTime** for marginal CI at 5-minute granularity. The same workflow can yield substantially different conclusions depending on which signal is used; in some regions and days, the marginal CI can dip near zero, suggesting periods where additional demand would be served by curtailed or excess renewable energy [2508.14625].

A different but related formulation appears in deadline-constrained workflow scheduling for mixed-energy datacenters. There, the system is given time intervals \(I_j\) with green power budget \(G_j\), and carbon cost is the excess of platform power over that budget:
$$
\mathcal{CC}=\int_0^D \max(0, P_t - G_j)\,dt \quad \text{for } t\in I_j.
$$
This formulation treats renewable availability as a capacity envelope rather than as a post hoc emissions coefficient [2605.27652].

## 3. Scheduling and execution-control mechanisms

One major family of techniques is day-ahead capacity shaping. Google’s Carbon-Intelligent Compute Management is a day-ahead, centralized, scheduler-agnostic control layer that gathers next-day carbon intensity forecasts, trains demand prediction models, fits CPU-to-power models, and then computes hourly Virtual Capacity Curves \(VCC^{(c)}(h)\) for each cluster. These VCCs preserve daily total capacity for flexible workloads while lowering hourly capacity during dirtier periods, causing flexible jobs to queue and run later in lower-carbon hours; inflexible workloads are unaffected [2106.11750].

Another family is demand response through explicit workload shifting. In Carbon Explorer, carbon-aware scheduling is modeled as moving a flexible fraction of datacenter demand from hours with the highest carbon intensity to hours with the lowest carbon intensity, subject to datacenter capacity. The scheduler is constrained by a **flexible workload ratio (FWR)** and by available server capacity. The reported impact is a **1%–21%** increase in 24/7 coverage from scheduling alone, at the cost of **6%–76% additional server capacity** [2201.10036].

When workflows are DAG-structured, task dependencies alter which deferrals are safe. PCAPS incorporates both time-varying carbon intensity and precedence-driven task importance by deferring tasks only when current carbon intensity is high relative to task importance. Its Spark prototype on a **100-node Kubernetes cluster** reports that a moderate configuration of **PCAPS** reduces carbon footprint by up to **32.9%** without significantly impacting the cluster’s total efficiency. The simpler CAP wrapper instead throttles cluster capacity without using task importance directly, providing easier integration but less fine-grained control [2502.09717].

For deadline-constrained workflows on heterogeneous datacenters, research splits between fixed-mapping and joint mapping-and-scheduling approaches. CaWoSched assumes a fixed task mapping and ordering and then shifts already-mapped task and communication operations into greener intervals. CWM generalizes this by jointly choosing processor subsets and task schedules under heterogeneous processor power/speed profiles and hard deadlines. Against the best version of CaWoSched, CWM achieves a median carbon cost reduction of **42%** when the deadline is two times the makespan of a carbon-agnostic baseline [2507.08725] [2605.27652].

A distinct mechanism appears in recurrent industrial analytics. CARINA combines lightweight instrumentation with peak time-aware worker management and local dashboard reporting. Its policies operate by reducing thread count, capping CPU affinity, reducing process priority during sensitive hours, and later increasing intensity to recover throughput. Preliminary policy analysis suggests that **peak-aware off-hours boosting** can reduce full-cycle energy load by about **9%** with roughly **7% runtime overhead**, whereas naive throttling can increase total energy through overhead effects [2605.24561].

## 4. Application domains and empirical systems

In industrial analytics, CARINA is evaluated on two sheet-metal database-generation workflows from an automotive OEM setting. The first required **1.48 million scenarios**, **180.30 h**, and **48.67 kWh**; the second required **3.66 million scenarios**, **274.75 h**, and **74.16 kWh**, corresponding to approximately **21.8 kg CO2e** and **33.2 kg CO2e**, respectively. These workflows are Excel-native parametric analytics workflows with a Python add-on for large-scale offline scenario generation, and they illustrate that recurring engineering analytics can be substantial energy consumers even outside hyperscale datacenter contexts [2605.24561].

Scientific workflow research has concentrated on Nextflow. A systematic evaluation across **seven real-world Nextflow workflows**—**Chip-Seq**, **MAG**, **Montage**, **Nano-Seq**, **Rangeland**, **RNA-Seq**, and **Sarek**—reports that temporal shifting can decrease emissions by **over 80%**, and that in some marginal-CI scenarios operational emissions can be reduced to near zero. The same study reports that resource scaling can decrease emissions by **67%** in favorable settings. Earlier exploration with **Chip-Seq** and **Rangeland** had already shown that full-workflow shifting can reduce emissions by roughly **30–64%** depending on workflow, flexibility window, and CI type, and that interrupted temporal shifting can outperform simple whole-workflow shifting [2508.14625] [2503.13705].

CI/CD has emerged as a second major application area. In a carbon-aware CI/CD architecture evaluated over **7,392 GitHub Actions workflow executions**, location shifting alone reduced emissions by **25.31%** relative to a round-robin baseline, while location plus time shifting achieved up to **31.20%** reduction overall when deadline buffers were available [2310.18718]. A later ecosystem-scale study estimated the 2024 GitHub Actions footprint at **150.5 MTCO2e** in the optimistic scenario, **456.9 MTCO2e** in the most likely scenario, and **994.9 MTCO2e** in the pessimistic scenario. It further found that about **33.9%** of total execution time was attributable to scheduled runs, and that shifting scheduled workflows to the lowest-carbon hour of the same day could reduce carbon emissions by up to **3.9%** in the most likely scenario [2510.26413].

Platform-level carbon awareness also appears in serverless and edge systems. GreenWhisk augments Apache OpenWhisk with carbon-aware load balancing in grid-connected mode and energy-aware routing in grid-isolated solar-plus-battery mode. In grid-isolated mode it reduces **downtime by 50%** and **total shutdowns by 50%** compared to default OpenWhisk, while preserving locality better than a purely greedy low-emissions routing policy [2409.03029]. CarbonCall, an edge framework for LLM-based function calling on an **NVIDIA Jetson AGX Orin**, combines dynamic tool selection, carbon-aware execution, and quantized model switching; it reports up to **52% reduction in carbon emissions**, **30% reduction in power consumption**, and **30% reduction in execution time** [2504.20348].

Carbon-aware execution is not restricted to scheduling in time and space. In carbon-aware interactive software services, the Strategy design pattern is used to host multiple alternative implementations with different energy consumption and output error, and a bilevel optimizer selects which strategy to use in each time slot according to forecast carbon intensity and request rates. The reported reductions range from **8% to 50%**, while controlling average output quality above a desired set-point [2405.12582].

## 5. Measurement, estimation, and observability

A large part of the field concerns how to obtain actionable carbon information when direct metering is unavailable. Ichnos estimates the carbon footprint of Nextflow scientific workflows post hoc by combining task-level workflow traces, user-configurable power models, and carbon-intensity data aligned with execution time. It reports an estimation error range of **3.9–10.3%**, and in a Glasgow example for a **2h 40m ampliseq** execution on **26 Sept 2024**, region-specific time-series CI yielded **0.33 gCO2e** whereas a coarse annual average yielded **18.65 gCO2e**, illustrating the distortion introduced by static CI values [2411.12456].

For pre-execution scheduling, runtime and energy prediction become critical. Augur addresses the case where workflows are new, modified, or moved to alternative infrastructure by profiling the target cluster and a lightly down-sampled version of the workflow, then predicting task runtime and energy before execution. It reports a median prediction error of **16.3\(\pm\)15.3%** compared to Ichnos and **18.2\(\pm\)14.7%** compared to Intel RAPL, with profiling overhead of **10.3% \(\pm\) 8.5%**. The method is explicitly positioned as a foundation for energy-aware and carbon-aware scheduling in heterogeneous clusters [2606.00348].

In settings where workflow recurrence is the central feature, observability can be intentionally lightweight. CARINA offers both whole-run and step-level tracking, aggregates runtime, worker intensity, estimated energy, translated carbon burden, and metadata per unit of work, and emits logs, summary metrics, plots, and dashboard artifacts. This design choice targets workstations and lightly managed servers, where code changes must be limited and direct device-level carbon metrology may be unavailable [2605.24561].

Large-scale CI/CD measurement has instead relied on bottom-up cloud accounting. The GitHub Actions ecosystem study builds on **Cloud Carbon Footprint**, **Etsy’s Cloud Jewel approach**, the **Green Software Foundation’s Software Carbon Intensity spec**, **Electricity Maps**, **Microsoft Sustainability** values for PUE and WUE, and the **workflow-telemetry action** to estimate CPU, memory, and network usage when workflows are re-executed. This methodology makes explicit that carbon-aware execution depends not only on task timing and placement but also on the fidelity of power, memory, storage, and network models [2510.26413].

## 6. Trade-offs, limits, and unresolved questions

The primary practical trade-off is between carbon reduction and completion time. Carbon-aware execution does not reduce energy or emissions automatically; under some conditions, slower execution increases both. CARINA reports that **low-priority only** execution slightly increases energy use and that **small batches (25)** perform worse because orchestration overhead dominates, whereas **large batches (100)** improve both runtime and energy [2605.24561]. Scientific workflow experiments show a related phenomenon at the hardware level: on **camelot**, the **powersave** governor made **Chip-Seq** and **RNA-Seq** about **2.5–3x slower** and increased energy use by about **1.3x**, yet in **California** powersave produced slightly less emissions than performance for Chip-Seq because runtime overlapped differently with the CI profile. At task level, a **4.0 GHz** run of **trimgalore** emitted **4.0 gCO2e**, whereas a **2.0 GHz** run emitted **9.5 gCO2e**, demonstrating that faster can be cleaner if it avoids dirtier intervals [2508.14625].

A second trade-off concerns operational versus embodied carbon. Carbon Explorer shows that carbon-aware scheduling can improve 24/7 renewable coverage, but often requires **6%–76% additional server capacity**, so embodied carbon can offset some operational gains. The same study concludes that **100% operational 24/7 carbon-free operation is not always carbon-optimal** once embodied carbon is included, and that batteries are often more effective than scheduling for closing short-term renewable gaps; combined batteries plus scheduling reduce total carbon footprint by **15%–65%** depending on region [2201.10036]. CarbonSim pushes this further by showing that newer machines do not always minimize total emissions: under lightly loaded workloads or cleaner electricity mixes, extending the useful life of existing hardware can reduce lifecycle carbon despite lower operational efficiency [2606.06438].

Reliability, SLA compliance, and hardware aging introduce additional constraints. In distributed heterogeneous datacenters, carbon- and reliability-aware workload migration explicitly models hardware failure, software failure, backup resource allocation, and server lifetime degradation. Numerical case studies report up to **21% reduction in total carbon emissions**, with SLA violations dropping to **less than 1%** and maximum delay increasing by only **5%** when backup resources are provisioned; backup servers account for roughly **19%–23%** of total dispatched servers [2504.00518]. This suggests that carbon-aware execution at production scale is often a reliability-aware control problem rather than a pure scheduling problem.

A further limitation is that many published gains are derived under idealized assumptions. Scientific workflow evaluations that report over **80%** temporal-shifting savings explicitly treat these as upper bounds under assumptions of perfect knowledge of task/runtime behavior, perfect CI forecasts, infinite resource availability, no resource contention, and no capacity constraints [2508.14625]. CARINA similarly acknowledges reliance on energy-load estimation rather than direct physical power measurement and on a local grid factor rather than continuously updated regional carbon-intensity data [2605.24561]. Finally, where quality is itself a constraint, carbon optimization can become a bilevel problem: carbon-aware software services show that the feasible objective is not absolute minimization of emissions, but minimization subject to an average quality threshold, with empirical reductions from **8% to 50%** [2405.12582].

Taken together, these results indicate that carbon-aware workflow execution is not a single scheduling heuristic but a family of measurement, prediction, and control methods. The common principle is to exploit workflow flexibility—temporal slack, interruptibility, resource heterogeneity, or implementation choice—while acknowledging that the carbon-optimal decision depends on the electricity signal, the workflow structure, the hardware fleet, and the operational constraints under which the workflow must still remain practical.

Source: https://www.emergentmind.com/topics/carbon-aware-workflow-execution