Carbon-Aware Workflow Execution

• Carbon-aware workflow execution is the scheduling and control of computational tasks that align energy use with lower-carbon periods using temporal flexibility and resource shifting.
• It employs techniques such as day-ahead capacity shaping, demand response, and adaptive resource scaling to optimize workflows across datacenters, scientific, CI/CD, and industrial domains.
• Empirical studies show reductions in emissions by up to 80% in favorable scenarios, highlighting its potential for sustainable computing despite trade-offs in runtime and resource capacity.

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 (Farooq, 23 May 2026, Radovanovic et al., 2021, Lechowicz et al., 13 Feb 2025, West et al., 20 Aug 2025).

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 (Farooq, 23 May 2026).

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 (Acun et al., 2022).

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 (West et al., 17 Mar 2025). 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 (Claßen et al., 2023).

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 (Farooq, 23 May 2026, Paramanayakam et al., 29 Apr 2025).

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 (Saavedra et al., 30 Oct 2025, Hans et al., 4 Jun 2026).

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 (West et al., 20 Aug 2025).

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 (Schweisgut et al., 26 May 2026).

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 $E$0 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 (Radovanovic et al., 2021).

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 (Acun et al., 2022).

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 (Lechowicz et al., 13 Feb 2025).

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 (Schweisgut et al., 11 Jul 2025, Schweisgut et al., 26 May 2026).

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 (Farooq, 23 May 2026).

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 (Farooq, 23 May 2026).

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 (West et al., 20 Aug 2025, West et al., 17 Mar 2025).

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 (Claßen et al., 2023). 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 (Saavedra et al., 30 Oct 2025).

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 (Serenari et al., 2024). 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 (Paramanayakam et al., 29 Apr 2025).

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 (Forti et al., 2024).

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 (West et al., 2024).

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$E$115.3% compared to Ichnos and 18.2$E$214.7% compared to Intel RAPL, with profiling overhead of 10.3% $E$3 8.5%. The method is explicitly positioned as a foundation for energy-aware and carbon-aware scheduling in heterogeneous clusters (West et al., 29 May 2026).

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 (Farooq, 23 May 2026).

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 (Saavedra et al., 30 Oct 2025).

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 (Farooq, 23 May 2026). 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 (West et al., 20 Aug 2025).

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 (Acun et al., 2022). 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 (Hans et al., 4 Jun 2026).

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 (Zhang et al., 1 Apr 2025). 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 (West et al., 20 Aug 2025). 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 (Farooq, 23 May 2026). 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% (Forti et al., 2024).

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.