Cloud Unit Economics: How BeReal calculates the cost of a Single Notification

Cloud unit economics is the practice of mapping cloud spend to a unit of business value: a transaction, an order, a daily active user. For BeReal, that unit is a single push notification in a single region: nearly all of the day's elastic spend concentrates into the minutes / hours around each send, so the cost of running the product is, quite literally, the cost of a notification. This article shows how they compute that number, and what it unblocked.

Google "cloud cost optimization" and every article lists the same tactics: rightsizing, reserved instances, spot, turning off dev instances at the weekend. They work but they optimize a workload nobody has priced. FinOps breaks when billing lives in one tool and the signal that explains it lives in another. The bill says what you spent; the event that explains the spend — a send, a batch job, a sale — lives in your own telemetry. Until the two meet on the same time axis, you can't tell an optimization from a rounding error, and product can't put infrastructure on the ROI side of any decision.

BeReal hit exactly this wall. The team wanted to give the UK its own regional notification a pure product decision and it sat blocked for a long time, not for lack of engineering will but for lack of a number: with daily billing granularity, nobody could say what one notification cost. Here's how hourly visibility and a per-notification price turned an unanswerable question into a decision that shipped in June 2026.

Why hourly granularity is a prerequisite for cloud unit economics

BeReal is a social network. Instead of asking people to stay connected to it all day, it sends users a notification once (or several times) a day, prompting them to show their friends what they are doing right then. BeReal operates in multiple regions and optimizes send times for maximum impact.

Their stack has to be extremely dynamic: absorb a massive usage spike in a few minutes, then cool down to reduce costs and improve efficiency. That means:

• a scale-up period ahead of each notification

• a period handling the load

• a scale-down within the following hour

With the daily visibility provided by the GCP console, those spikes were lost, because the GCP billing day cuts at Pacific time. Depending on where notifications landed across time zones, a calendar day could contain three, four, or five notifications. You cannot see the scale-up and scale-down.

Computing a cost per notification per region was impossible. The team had attempted a homemade hourly script using BigQuery export data, but the numbers were not solid enough to bring to product or finance. The cost of computing this cost is not obvious either: running queries against the raw export can easily get expensive.

Hourly is not for everyone. Daily granularity is enough for most workloads anything whose cost pattern is longer than a day. Hourly pays off when the event driving your elastic spend lives inside a day: a notification fanout, a nightly ETL, a drop sale, a batch job.

How BeReal prices a single notification

Price the unit of work, not the month. For BeReal, that unit is one notification in one region. The recipe: hourly granularity; filter to the services that scale with the event (compute, some egress storage is a static cost, so it is out); ingest the scale-up trigger as a labeled event, so that every spike on the cost curve has a name, a region and a timestamp; read the full scale-up → load → scale-down window as one unit. Cutting at send time undercounts: pre-provisioning is where the money goes.

"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."

Thomas Lorreyte, Head of Infrastructure at BeReal

Example of cloud unit economics: a formula and an external metric imported through BigQuery (illustrative figures)

From blocked to shipped: pricing a new region before building it

Western Europe shared a single "Time to BeReal" notification. When it fires at 7pm in Paris, it lands at 6pm in London, past the window where engagement holds up. Timing is one of the most sensitive variables in BeReal's engagement: the users only have 2 minutes to post. Some hours perform dramatically worse than others. BeReal wanted to give the UK its own regional notification, but the decision sat blocked because the team could not size it. Adding a region means adding a notification, which means a new compute spike, and with daily granularity BeReal could not isolate the cost of a single notification. No cost number meant no ROI case, and on a small team, product will not commit engineering time to a feature it cannot price.

"We could have split the region before. We just couldn't say what it would cost, and on a small team, product won't sign off on a feature without an ROI number up front."
Thomas Lorreyte, Head of Infrastructure at BeReal

Hourly granularity gave product and engineering a credible per-notification cost, so the marginal cost of a UK send could finally sit on one side of an equation. On the other side: better timing does not move a single metric in isolation. More posts create more ad inventory, send-time quality has outsized downstream impact. The alternative was priced too: cheaper on paper, but the per-notification cost let the team compare both options against the engagement each would produce.

Product and finance signed off, and the dedicated UK region shipped in June 2026.

Cost per DAU: splitting static from elastic spend

Cost per notification answers the question "what does one event cost?". Paired with a business unit, it becomes unit economics: BeReal splits cost per DAU into static (photo storage, baseline services) and elastic (everything that scales with traffic: the notifications). Static tracks user growth and moves slowly; elastic is where every optimization shows up, which is why the two are tracked separately.

The split also changes how a rising cost per DAU is read: a climbing static share means storage is outpacing user growth, a conversation about retention of old content; a climbing elastic share means something in the send path got more expensive per user and the per-notification grid says which region and which hour.

How to measure your own unit costs

Four questions before touching any tooling.

• What discrete event drives your elastic cost: a backfill job, a customer-triggered pipeline, a fanout, a sale?

• What is its full window ? from the moment capacity starts moving to the moment it is back at baseline (anything under 24h benefits from hourly granularity) ?

• What business outcome does one event map to: a post, an impression, a purchase?

• And who needs the number: engineering to defend optimizations, product to scope features, finance to review the bill?

Write the four answers down: they are the spec for everything below.

Hourly costs from the GCP billing export

The DIY route runs through the GCP detailed billing export to BigQuery. Here is the shape of it:

1. Enable the detailed usage cost export (Billing → Billing export → Detailed usage cost). If your BigQuery dataset lives in the US or EU multi-region, data is backfilled retroactively from the start of the previous month (the initial backfill can take up to five days); a single-region dataset only collects from the day you enable it. Either way, turn it on before you need it — one month of history is not much of a baseline.

2. Group by hour on usage_start_time, not on the export date or invoice day — the invoice day cuts at Pacific time, which is exactly how the spikes got lost in the first place.

3. Filter to the services that scale with your event (service.description IN (...)) and net the credits into each row: CUD discounts arrive as credit rows (credits.type = "COMMITTED_USAGE_DISCOUNT") attached to the usage they cover, so summing credits.amount into each hour works directly — drop them and your spike costs will be overstated. The query below nets all credits (CUDs, sustained-use discounts, promotions), which is the right default when the question is "what did this hour actually cost us." (Note since January 2026, Google has migrated Flex CUDs to a "multiprice" model where the discount applies directly to the SKU's effective price instead of arriving as a credit row — one less thing for the query to net.)

4. Normalize by the unit economics: Import from Amplitude, Google Sheet, BigQuery.

A minimal starting query without unit economics:

WITH src AS (
  SELECT
    service.description AS service,
    usage_start_time AS s,
    usage_end_time AS e,
    cost + (SELECT COALESCE(SUM(c.amount), 0) FROM UNNEST(credits) c) AS net_cost
  FROM `project.dataset.gcp_billing_export_resource_v1_XXXXXX`
  -- _PARTITIONTIME is *export* time, not usage time: rows for a given usage hour
  -- can land in partitions a day or two later, so pad the upper bound...
  WHERE DATE(_PARTITIONTIME) BETWEEN @start AND DATE_ADD(@end, INTERVAL 2 DAY)
    -- ...and bound the actual usage window separately.
    AND usage_start_time >= TIMESTAMP(@start)
    AND usage_start_time <  TIMESTAMP(DATE_ADD(@end, INTERVAL 1 DAY))
    -- taxes, adjustments, and rounding rows arrive in monthly lumps;
    -- spread across hours they produce phantom spikes.
    AND cost_type = 'regular'
    AND service.description IN ('Compute Engine', 'Kubernetes Engine')
    AND project.id = 'costory-production'
    -- GKE stamps the cluster as a system label; use your own label key
    -- only if you actually set one on the resources.
    AND (SELECT value FROM UNNEST(labels) WHERE key = 'goog-k8s-cluster-name') = 'OndemandCluster'
)
SELECT
  TIMESTAMP_TRUNC(h, HOUR) AS hour,
  service,
  SUM(net_cost / GREATEST(TIMESTAMP_DIFF(e, s, HOUR), 1)) AS net_cost
FROM src,
UNNEST(GENERATE_TIMESTAMP_ARRAY(
  s,
  GREATEST(TIMESTAMP_SUB(e, INTERVAL 1 HOUR), s),
  INTERVAL 1 HOUR
)) AS h
GROUP BY hour, service
ORDER BY hour

The minimal query works for a one-time example but falls short in three ways:

1. Mixed granularity. Some services report hourly (Compute Engine, Cloud SQL), others daily Cloud Storage among them. The query above spreads a daily row evenly across its 24 hours, which is better than nothing but still fiction: your 2 a.m. hour quietly absorbs 1/24th of a full day of GCS costs it may have had nothing to do with. Before an "hourly" total means anything, the daily rows need to be spread or excluded per service, deliberately.

2. Shared costs. Egress doesn't arrive labeled with your event; it needs an allocation rule to land on the right notification, region, and hour. This is what we do with Virtual Dimensions

3. Query cost. Scanning the raw export on every question gets expensive. The partition filter in the query above contains it; the real fix is a scheduled hourly aggregate table, so the expensive scan runs once instead of on every question.

The first two are the actual work. Costory handles all three and exposes an MCP server so you can operate everything from Claude instead of maintaining the SQL yourself.

Conclusion:

Unit economics is not a dashboard; it is a measurement decision. The tactics everyone publishes (rightsizing, reservations, spot) come after the measurement, not before: they optimize a workload someone has already priced and defended. Put a dollar figure on the unit of work your product ships, and let engineering and product argue against that number !

Get started at costory.io — 15-day free trial, $250/month under $10M annual spend.

FAQ

What is cloud unit economics?

Cloud unit economics maps cloud spend to a unit of business value — a transaction, an order, a notification, a daily active user — instead of reading it as a monthly bill. It turns "we spent $X on compute" into "one notification costs $Y to serve," a number engineering, product, and finance can all act on.

How do you choose the unit of work?

Pick the discrete event that drives your elastic spend: a notification fanout, a batch job, a customer-triggered pipeline, a sale. The right unit maps to a business outcome (a post, an impression, a purchase) so cost can sit on one side of an ROI equation.

When do you need hourly cloud cost granularity instead of daily?

When the event driving your elastic spend lives inside a single day. Daily granularity is enough for workloads whose cost pattern is longer than a day; hourly is what makes a cost per event computable for spikes like sends, ETLs, or drop sales — including the pre-provisioning window before the event, which is where the money goes.

How is cost per DAU calculated?

Split total cloud cost into static (storage, baseline services) and elastic (everything that scales with traffic), then divide each by daily active users. The static share tracks user growth; the elastic share is where optimizations and product decisions show up, so the two are tracked separately.