Problem
The default patrol-interval is 12h. The WattTime forecast covers ~24 hours of future data but is regenerated every ~5 minutes. With a 12h patrol, the ConfigMap can be up to 12 hours stale, meaning consumers see timestamp windows from hours in the past with no useful current data.
Impact
A consumer trying to act on the current carbon intensity (e.g. a Kubernetes operator scheduling workloads) would be reading data generated up to 12 hours ago. If the forecast was fetched at 08:00, by 20:00 the earliest forecast points predate the current time and the ConfigMap no longer covers "now".
Suggestion
Set the default to 1h or 2h. This keeps the ConfigMap fresh while staying well within WattTime and Electricity Maps API rate limits.
Problem
The default
patrol-intervalis12h. The WattTime forecast covers ~24 hours of future data but is regenerated every ~5 minutes. With a 12h patrol, the ConfigMap can be up to 12 hours stale, meaning consumers see timestamp windows from hours in the past with no useful current data.Impact
A consumer trying to act on the current carbon intensity (e.g. a Kubernetes operator scheduling workloads) would be reading data generated up to 12 hours ago. If the forecast was fetched at 08:00, by 20:00 the earliest forecast points predate the current time and the ConfigMap no longer covers "now".
Suggestion
Set the default to
1hor2h. This keeps the ConfigMap fresh while staying well within WattTime and Electricity Maps API rate limits.