Skip to main content
Hourly cloud cost granularity turns event-driven infrastructure into a measurable cost unit. This recipe shows how to price one bursty workload event, using BeReal’s daily Time to BeReal notifications as the worked example.
Co-written with Thomas Lorreyte, Head of Infrastructure at BeReal.

​
When to use this recipe

Use hourly granularity when your infrastructure spend is driven by discrete events rather than steady-state traffic. The pattern shows up in workloads such as:
  • Push notification fanouts, including BeReal’s Time to BeReal notifications, marketing pushes, and scheduled email blasts.
  • Scheduled batch jobs, such as nightly ETL, billing runs, periodic reconciliation, and ML training.
  • Live event spikes, including sports streams, drop sales, product launches, and regional rollouts.
  • Cron-driven workloads where you can name the recurring event that creates elastic cost.
If you can name the discrete unit that drives most of your elastic cost, that unit deserves its own cost number.

​
Why daily granularity falls short

Daily cost data is the default in many AWS, GCP, and Azure billing workflows. It works for steady workloads where today looks like yesterday. It breaks down when spend is concentrated into short windows. Common failure modes:
  1. Multiple events land on the same day. Three batch jobs on Monday and one on Tuesday make day-over-day comparison hard to interpret.
  2. Events shift across time zones. Billing cutoffs are usually UTC or US Central, so a single calendar day can contain a different count of events depending on where they fired.
  3. Spikes are short relative to the day. A 90-minute compute burst averaged into 24 hours can disappear into the daily total.
The downstream consequence is practical: you cannot price one event in dollars, measure the ROI of optimization work, or scope a product decision that adds, moves, or removes one event.
Hourly granularity is part of the Copilot Plus tier. It is built for teams running bursty workloads where per-event cost matters. If your infrastructure is mostly steady-state, daily granularity in the base tier is usually enough.

​
The recipe

1

Name the event

Pick the discrete thing that drives your cost: a push notification, batch run, campaign send, or training job. Write down its rough duration and frequency.
2

Switch Cost Explorer to hourly

In , set granularity to hourly and filter to the services that scale with the event. This is usually compute, and sometimes egress or storage I/O.
3

Anchor the event in time

Ingest your scale-up triggers as events through the Events integration. Each spike is labeled and aligned with the cost curve, so the per-event window is clear.
4

Compute the per-event cost

Read the cost across the full event window: scale up, run, and scale down. Treat that window as one unit. Repeat across several events to calculate the mean and variance.
5

Operationalize the metric

Bring the per-event cost into recurring reporting. Engineering, product, and finance should read the same number when they discuss the workload.

​
Worked example: BeReal

BeReal pushes four daily Time to BeReal notifications worldwide. Each one fires at a randomized time and opens a two-minute posting window. Infrastructure-wise, each notification is a clean, repeatable cost unit:
  • Clusters scale up ahead of each notification.
  • They handle the load through the posting window.
  • They scale back down within the hour.
With daily aggregation, BeReal hit two specific problems:
  • Variable count per day. The GCP billing cutoff is US Central. Depending on where notifications landed across time zones, a calendar day could contain three, four, or five notifications.
  • No trustworthy per-notification number. The team had attempted a homemade hourly script, but the numbers were not solid enough to bring to product or finance.
With Costory’s hourly granularity, the picture changed:
  • Per-notification cost. A Japan notification costs X. A US notification costs Y. The numbers stay stable regardless of which calendar day they land on.
  • Optimization ROI in dollars. Code changes on scale-up logic are measured against the next notification, not a noisy daily average. Wins and regressions both show up quickly.
  • One view across teams. Product scopes new features against the same numbers finance uses to review the bill.
  • Defensible scaling decisions. When infrastructure spend grows, the per-notification number shows whether the team is becoming more efficient or less efficient.

Thomas Lorreyte, Head of Infrastructure at BeReal

“It was a drastic change from a product decision standpoint. We can now quantify, to the dollar, every optimization we ship on the moment infrastructure.”

​
Pair per-event cost with a business unit

Per-event cost answers what one event costs. Pairing it with a business unit, such as DAU, posts, impressions, processed records, or customers, turns it into for the workload. BeReal pairs per-notification cost with cost per DAU, split between:
  • Static cost: storage of historical photos and baseline workloads.
  • Elastic cost: the part that scales with traffic.
The combined metric supports day-to-day decisions:
  • Engineering defends optimization work. Ship a scale-up change, measure the delta in dollars per DAU per notification, and report the result.
  • Product scopes features against ROI. Price a new notification or cadence change against a credible cost-per-DAU-per-notification number, then weigh it against expected business lift.
See Unit Economics for the recurring metric workflow.

​
Adapt it to your stack

Use these prompts to find the equivalent event in your infrastructure:
  • Name the discrete event that drives most of your elastic cost.
  • Define the full window: scale up, run, and scale down. Anything under 24 hours can benefit from hourly granularity.
  • Pick the outcome that maps to one event, such as a post, an impression, a processed record, or a customer. One business unit per event is the cleanest pairing for ROI.
  • Identify who needs the number. Engineering uses it to defend work, product uses it to scope features, and finance uses it to review the bill.

​
Next steps

Explore hourly costs

Switch Cost Explorer to hourly granularity and inspect your spike shapes.

Ingest events

Overlay scale-up triggers and workload events on the cost timeline.

Define unit economics

Turn per-event cost into a per-user or per-outcome metric.

Correlate costs and events

Tie cost shifts back to the events that caused them.

​
FAQ

No. Hourly granularity changes the time bucket in the billing data. AWS, GCP, and Azure exports still arrive with a delay, and Costory processes the data after it is available. See Data Refresh for provider freshness details.
You can start with manual time windows, but events make the metric defensible. Once scale-up triggers are ingested, each spike is labeled on the cost curve and easier to compare over time.
That is the main reason to use hourly granularity. Instead of explaining one daily total, split the day into event windows and calculate cost per event.
Last modified on June 1, 2026