Consider changing the default cron to day instead of night for lower carbon impact

[liamlaverty]

Hey, love the action thank you for creating it!

Could the default cron time be moved to the daytime, instead of midnight? The marginal unit of energy at night time typically generates more carbon than during the day, due to the lack of solar power. As such, the action in its default form creates excess demand for high-carbon energy sources.

Longer-term, would you consider integrating with the Carbon Aware SDK from Green Software Foundation? https://greensoftwarefoundation.atlassian.net/wiki/spaces/~612dd45e45cd76006a84071a/pages/17137665/Opensource+Carbon+Aware+SDK, integrating this feature would automatically move the action's time around, depending on the carbon intensity of the energy mix.

[ArneTR]

Hey Liam, thanks for raising the issue!

I think you raise a valid point here, especially to highlight the possibility of savings through time shifting.

I want to however also include the other opinions on the topic. Have you for instance read Adrian Cockrofts piece on the possible downsides of this approach? https://adrianco.medium.com/dont-follow-the-sun-scheduling-compute-workloads-to-chase-green-energy-can-be-counter-productive-b0cde6681763

The other downside, which is in most grids the case, is that even if typically the mix is greener during the day there might be no actual saving in the concrete instance of the run due to rather the marginal energy sources (gas here in germany) being used to satisfy additional demand.

Very much interested on your views on both points.

If we change the time for the default cron I would argue we should at least provide both arguments in the docs :)

[liamlaverty]

Hi Arne, That's an interesting set of discussions, thanks.

Looking through Cockroft's piece, and the linked GSF github thread[1] there's still a lot of debate about marginal versus average unit of energy being the main thing to target. I've tried to summarise below:

• Lowest marginal emissions are often at night
• Lowest average emissions are usually during the day
• This differs regionally depending on energy mix
• Targeting the lowest marginal emissions will consume the lowest intensity energy, slightly reducing energy in the short-term, though because most peak providers are coal/gas, the marginal carbon intensity is roughly the same day or night[3]
• Targeting the lowest average emissions may incentivise energy providers to bring more solar into the energy mix, reducing emissions in the long-term
  • This would however also incentivise cloud providers to bring in more physical computers to satisfy computation demand, potentially pushing the Scope2 emissions into Scope3
• Everybody running cron jobs on the hour is bad for both Scope 2 emissions through peaking energy demand, and Scope 3 emissions through the requirement for additional compute power[2]
• Spiking energy demand is typically met by carbon-intense providers, irrespective of the availability of clean energy, and marginal emissions are actually relatively high all the time[3].

---

I'm not too sure what I think now. Running a tool like Carbon Aware SDK might be a good idea to defer the strategy to that organisation. However it'd come as a substantial change to the Action, and would incur ongoing maintenance for your team down the line. From Cockroft's article, "cron-jittering" might be the most impactful & simplest change, just moving it away from the "on the hour" approach when all the other crons are increasing computation demand.

[1] Green-Software-Foundation/sci#351
[2] https://adrianco.medium.com/dont-follow-the-sun-scheduling-compute-workloads-to-chase-green-energy-can-be-counter-productive-b0cde6681763
[3] Green-Software-Foundation/sci#351 (comment)