What's Changed
✨ New: HOURLY granularity
You can now set granularity: HOURLY on a metric to export cost data at hourly resolution. Each hour in a rolling lookback window is exported as its own time series, distinguished by a new PeriodStart label (e.g. PeriodStart="2026-07-13T06:00:00Z").
Configuration
metrics:
- metric_name: aws_hourly_cost_usd
granularity: HOURLY
hourly_time_range_hours: 24 # Optional (default 24). How many past hours to export, 1–336.
data_delay_days: 0 # Optional. hourly_time_range_hours + data_delay_days*24 must stay ≤ 336.- The query window is UTC-aligned to the top of the hour, so only complete hourly buckets are exported.
- Every poll re-fetches the whole window, so the metric self-heals: late-arriving or corrected AWS data is picked up on the next scrape. The window is therefore decoupled from
polling_interval_seconds— no need to poll more than once an hour. DAILYandMONTHLYmetrics are unaffected (noPeriodStartlabel, no behavior change).
Before you enable it
- ⚠️ HOURLY granularity must be opted into on the AWS Cost Explorer Settings page and incurs additional AWS charges.
- AWS only retains hourly cost data for the past 14 days, which is why
hourly_time_range_hoursis capped at 336.
Querying in Prometheus
The hour's real event time lives in the PeriodStart label, not in the sample timestamp (which is scrape time). Chart per-hour cost with e.g. sum by (PeriodStart) (aws_hourly_cost_usd), and avoid naive sum(...) / rate() over the raw metric, since all hours in the window are live simultaneously and would double-count. See the "Querying HOURLY metrics" section in the README for details.
Full list
Full Changelog: v1.1.5...v1.2.0