Using Energy Prediction To Better Plan Cron Jobs
Since the Belgian government mandated the use of digitized smart energy meters we’ve been more carefully monitoring our daily energy demand. Before, we’d simply chuck all the dishes in the machine and program it to run at night: no more noise when we’re around. But now, consuming energy at night is costing us much more. The trick is to take as little as possible from the grid, but also put as little as possible back. In short, consume (or store) energy when our solar panels produce it. That dishwasher will have to run at noon instead. The same principle applies to running demanding software: CPU or GPU-intensive tasks consume an awful amount of energy, so why run them when there’s less energy available locally, thus paying more? Traditionally, these kinds of background jobs are always scheduled at night using a simple cron expression like that says “At 03:00 AM, kick things in gear”. But we can do better. At 03:00 AM, our solar panels are asleep too. Why not run the job when the sun is shining? Probably because you don’t want to interfere with the heavy load of your software system during the day thanks to your end users. It’s usually not a good idea to start generating PDF files en masse , clogging up all available threads, severely slowing down the handling of incoming HTTP requests. But there’s still a big margin to improve the planning of the job: instead of saying “At 03:00 AM exactly ”, why can’t we say “Between 01:00 AM and 07:00 AM”? That’s still before the big HTTP rush, and in the early morning, chances are there’s more cheap energy available to you. Cooking up a simple version of this for home use is easy with the help of Home Assistant. The following historical graph shows our typical energy demand during the last week (dreadful Belgian weather included): Home Assistant history of P1 Energy Meter Demand from 24 Nov to 28 Nov. Care to guess what these spikes represent? Evenings. Turning on the stove, the oven, the lights, the TV obviously creates a big spike in energy consumption, and at the same time, the moon replacing the sun results in us taking instead of giving from the energy grid. This is the reason the government charges more then: if everybody creates spikes at the same time, there’s much more pressure on the general grid. But I can’t bake my fries at noon when I’m work and we aren’t supposed to watch TV when we’re working from home… That data is available through the Home Assistant API: . Use an authorization header with a Bearer token created in your Home Assistant profile. If you collect this for a few weeks and average the results you can make an estimated guess when demand will be going up or down. If you want things to get a bit more fancy, you can use the EMHASS Home Assistant plug-in that includes a power production forecast module. This thing uses machine learning and other APIs such as https://solcast.com/ that predicts solar power—or weather in general: the better the weather, the more power available to burn through (given you’ve got solar panels installed). EMHASS also internalizes your power consumption habits. Combined, its prediction model can help to better plan your jobs when energy demand is low and availability is high. You don’t need Home Assistant to do this, but the software does help smooth things over with centralized access to data using a streamlined API. Our energy consumption and generation is measured using HomeWizard’s P1 Meter that plugs into our provider’s digital meter and sends the data over to Home Assistant. That’s cool if you are running software in your own basement, but will hardly do on a bigger scale. Instead of monitoring your own energy usage, you can rely on grid data from the providers. In Europe, the European Network of Transmission System Operators for Electricity (ENTSO-E) provides APIs to access power statistics based on your region—including a day-ahead forecast! In USA, there’s the U.S. Energy Information Administration (EIA) providing the equivalent, also including a forecast, depending on the state. ENTSO-E returns a day-ahead pricing model while EIA returns consumption in megawatthours, but both statistics can be used for the same thing: to better plan that cron job. And that’s exactly what we at JobRunr managed to do. JobRunr is an open-source Java library for easy asynchronous background job scheduling that I’ve had the pleasure to work on the last year. Using JobRunr, planning a job with a cron expression is trivial: But we don’t want that thing to trigger at 3 AM, remember? Instead, we want it to trigger between an interval, when the energy prices are at their lowest, meaning when the CPU-intensive job will produce the least amount of CO2 . In JobRunr v8, we introduced the concept of Carbon Aware Job Processing that uses energy prediction of the aforementioned APIs to better plan your cron jobs. The configuration for this is ridiculously easy: (1) tell JobRunr which region you’re in, (2) adjust that cron. Done. Instead of , use : this means “plan at somewhere between an hour before 3 AM to four hours later than 3 AM, when the lowest amount of CO2 will be generated”. That string is not a valid cron expression but a custom extension on it we invented to minimize configuration. Behind the scene, JobRunr will look up the energy forecasts for your region and plan the job according to your specified time range. There are other ways to plan jobs (e.g. fire-and-forget, providing s instaed of a cron, …), but you get the gist. JobRunr’s dashboard can be consulted to inspect when the job is due for processing. Since the scheduled picks can sometimes be confusing—why did it plan this at 6 AM and not at 7?—the dashboard also visualizes the predictions. In the following screenshot, you can see being planned at 15:00 PM, with an initial interval between 09:39 and 17:39 (GMT+2): The JobRunr dashboard: a pending job, to be processed on Mon Jul 07 2025 at 15:00 PM. There’s also a practical guide that helps you get started if you’re interested in fooling around with the system. The idea here is simple: postpone firing up that CPU to the moments with more sunshine, when energy is more readily available, and when less CO2 will be generated 1 . If you’re living in Europe/Belgium, you’re probably already trying to optimize the energy consumption in your household the exact same way because of the digital meters. Why not applying this principle on a grander scale? Amazon offers EC2 Spot Instances to “optimize compute usage” which is also marketed as more sustainable, but this is not the same thing. Shifting your cloud workout to a Spot Instance will use “spare energy” that was already being generated. JobRunr, and hopefully soon other software that optimized jobs based on energy availability, plans using marginal changes. In theory, the decision can determine the fuel resource as high spikes force high-emission plants to burn more fuel. In always-on infrastructure, spare compute capacity is sold as the Spot product—there’s no marginal change. The environmental impact of planning your job to align with low grid carbon intensity is much higher—in a good way—compared to shifting cloud instance types from on-demand/reserved to Spot. Still, it’s better than nothing, I guess. If the recent outages of these big cloud providers have taught us anything, it’s that on-premise self-hosting is not dead yet. If you happen to be rocking Java, give JobRunr a try. And if you’re not, we challenge you to implement something similar and make the world a better place! You probably already noticed that in this article I’ve interchanged carbon intensity with energy availability. It’s a lot more complicated than that, but for the purpose of Carbon Aware Job Processing, we assume a strong relationship between the electricity price and CO2 emissions. ↩︎ Related topics: / java / By Wouter Groeneveld on 28 November 2025. Reply via email . You probably already noticed that in this article I’ve interchanged carbon intensity with energy availability. It’s a lot more complicated than that, but for the purpose of Carbon Aware Job Processing, we assume a strong relationship between the electricity price and CO2 emissions. ↩︎