v1.2.0

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.
• DAILY and MONTHLY metrics are unaffected (no PeriodStart label, 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_hours is 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

• feat: Add support for Hourly granularity by @1azunna in #39

Full Changelog: v1.1.5...v1.2.0