A cloud bill increased 22% from March to April. Without context the number looks alarming. With context — traffic grew 35% in the same window, MAU grew 28%, completed transactions grew 41% — the per-unit cost actually dropped. The bill is bigger because the business is bigger and per-unit efficiency improved. The cost number alone is half the conversation; the unit-economics number is the other half.
ZopNight ships the unit-economics overlay on Cost Reports. Pin a business denominator (Monthly Active Users, API Requests, Completed Transactions, Signups, or a custom metric) and the Cost Over Time chart gains a secondary axis showing cost-per-unit. The question “are we getting more efficient or less” becomes a chart you can pull up in a meeting, not a quarterly board exercise that requires three teams to assemble.
This post covers what the overlay does, the two ingest paths for the denominator data, how the three scopes (Summary / Teams / Tags) compose, the Test Fetch validation that catches bad endpoint configs before the cron picks them up, and how to set the overlay up day one.
Why a cost number alone is half the conversation
The board does not ask “is the bill big.” The board asks “is the bill scaling efficiently.” Engineering leadership has the same question with different words: “is our infrastructure becoming more or less leveraged per unit of business output.” A cost number cannot answer either question without a denominator.
| What changed | Cost number alone | Cost per unit |
|---|---|---|
| Bill +22%, MAU +35% | Looks bad | Per-MAU dropped 9.6%; efficiency improved |
| Bill -10%, MAU -25% | Looks good | Per-MAU rose 20%; efficiency worsened |
| Bill flat, MAU +50% | Ambiguous | Per-MAU dropped 33%; clear win |
| Bill flat, MAU -50% | Ambiguous | Per-MAU doubled; clear problem |
Each row shows the same cost trajectory but a different efficiency outcome depending on the denominator’s direction. The cost trajectory in isolation is misleading; the per-unit trajectory is the signal.
The denominator has to come from the customer because the cloud cannot see it. AWS Cost Explorer knows about EC2 instances; it does not know about active users. The customer’s product analytics pipeline knows about active users; it does not know about EC2 cost. The overlay’s job is to join the two on a shared date axis and render the ratio.
What the overlay actually does
The overlay is one feature, two displays. The Cost Over Time chart on the Cost Reports page gets a second Y axis. Cost stays on the left axis as before. The denominator’s value goes on the right axis. The ratio (cost ÷ denominator) becomes the line the operator actually watches.
| Curated metric | Typical use | Denominator unit |
|---|---|---|
| Monthly Active Users (MAU) | SaaS efficiency | Users |
| Daily Active Users (DAU) | High-frequency engagement | Users |
| API Requests | B2B platform efficiency | Requests (often per 1K for readability) |
| Completed Transactions | Fintech, e-commerce | Transactions |
| Signups | Growth-stage cost-of-acquisition | Signups |
| Custom | Anything with a daily numeric value | Operator-defined |
The five curated metrics ship as quick-add chips above the chart. Click a chip, point it at your data source, and the overlay renders the next time the chart refreshes. Custom metrics use the same shape through the Manage metrics drawer; the only difference is the operator names the denominator and its unit.
The overlay does not change how cost is computed. The cost data on the left axis is the same data the existing report already shows. The overlay adds the right axis and the ratio; everything else is unchanged.
Two ingest paths: CSV upload + HTTPS Pull
The denominator data has to enter ZopNight somehow. Two paths handle the two common cases.
| Path | When to use | Mechanics | Limits |
|---|---|---|---|
| CSV upload | Backfill historical data, one-off exploration, quarterly board prep | Drag a date,value CSV into the metric drawer | 1 MB or 5,000 rows per upload |
| HTTPS Pull | Ongoing daily denominator values from the customer’s pipeline | Register an endpoint + auth; ZopNight fetches at 04:15 UTC daily | 5 MB body cap, 5,000 rows per fetch, 30-second timeout |
CSV is the right ingest for the first 30 days of exploration. The operator pulls a date-and-value series from their analytics tool (Amplitude, Mixpanel, Looker, Snowflake), drops it into the overlay, and sees whether the cost-per-unit story is the one they expected. If the story checks out, switch to Pull for ongoing data; if it does not, the CSV upload was a cheap experiment to discover the right denominator.
Pull is the right ingest once the chart is settled. The customer registers an HTTPS endpoint that returns a {date, value} JSON array. ZopNight’s cron fetches once a day at 04:15 UTC, parses the response, normalises values, and updates the metric. The 04:15 cadence assumes the customer’s pipeline has completed the previous day’s aggregation by then; the operator can adjust if their pipeline lands later.
The Pull endpoint supports four auth modes:
| Auth mode | Header / form |
|---|---|
| None | Public endpoint (rare for real production) |
| Bearer | Authorization: Bearer <token> |
| Basic | Authorization: Basic <base64> |
| Custom header | Operator-named header with operator-supplied value |
Switching from one auth mode to another (or from CSV to Pull and back) is supported without data loss. The metric’s history persists; only the ingest mechanism changes. Switching to Pull with bearer / basic / custom auth requires the credentials in the same call so a metric cannot end up in a state where the cron silently fails every fetch because the auth is empty.
Three scopes: Summary, Teams, Tags
The overlay works at three scopes, matching the three tabs on the Cost Reports surface.
| Scope | What the overlay shows | When the question matches |
|---|---|---|
| Summary tab | Org-wide cost ÷ org-wide denominator | ”Are we as a company getting more or less efficient” |
| Teams tab | Per-team cost ÷ per-team denominator (or org fallback) | “Which teams are getting more or less efficient” |
| Tags tab | Per-tag cost ÷ per-tag denominator | ”Per-customer / per-feature / per-product unit economics” |
The Teams-tab nuance is worth explaining. Most customers have org-wide MAU data; few have per-team MAU data. When a team-dimensioned denominator does not exist for the picked metric, the API response sets fellBackToOrgScope: true and the UI shows the team cost divided by the org-wide users. The operator sees “this is the team’s share of the org user base, not the team’s own user count” rather than getting a misleading per-team ratio.
For customers who do have per-team denominators (typically B2B platforms where teams own customer-facing surfaces with their own MAU), the per-team overlay renders the true ratio. The fallback is transparent; the operator always knows which case they are looking at.
The Tags-tab scope is the most powerful for SaaS customers. Tag your resources with customer-id (see the per-customer cost work) and the overlay can render cost-per-customer when the denominator is keyed on the same dimension. The result is a per-customer efficiency view that surfaces the customers whose unit economics are healthy versus the ones who cost more per use than they should.
Switching sources, recreating metrics
Two operational behaviours that matter when running the overlay over months and quarters:
| Operation | What happens |
|---|---|
| CSV-created metric switched to Pull | History preserved; ongoing values come from the Pull endpoint |
| Pull-created metric switched to CSV | History preserved; ongoing values come from CSV uploads |
| Auth swapped on a Pull metric (e.g., bearer → custom header) | Re-validated synchronously; cron picks up the new auth on next fetch |
| Metric deleted | Name tombstoned internally; recreate-with-same-name works immediately |
The tombstone-on-delete pattern matters because the typical operator workflow is “create a metric, realise the data shape is wrong, delete and recreate.” A name conflict on recreate is the wrong UX. ZopNight handles the tombstone on the server side; the operator just clicks delete then create.
The Test Fetch button
The most common failure mode for a Pull-configured metric is “the cron silently fails every day because the auth was wrong / the endpoint moved / the response shape changed.” The customer does not discover the failure until they open the chart in the board meeting.
The Test Fetch button on the metric drawer runs the full Pull path synchronously on demand. The customer clicks Test Fetch, the cron job’s exact code path executes once, the customer sees the response (success with a row count, or a categorised error) in seconds. Endpoint mistakes are caught before the daily cron tries them.
The full Pull pipeline runs with SSRF guards. Private IP ranges, loopback, link-local, CGNAT, IPv6 ULA and link-local are all blocked. The 30-second timeout, 5 MB body cap, and 5,000-row cap apply to the test path as they do to the cron path. The behaviour seen during Test Fetch is the behaviour the cron will see; there is no test-only relaxation.
| Test Fetch outcome | What it means | Operator action |
|---|---|---|
| Success (N rows ingested) | Endpoint reachable, auth correct, response shape valid | Save the metric; cron picks it up tomorrow |
| 401 / 403 from endpoint | Auth not accepted | Fix the credentials in the metric config |
| Connection blocked (SSRF guard) | Endpoint resolves to a private IP range | Use a public-routable endpoint or set up a proxy |
| Response too large | Endpoint returned >5 MB or >5,000 rows | Add server-side pagination or row limits |
| Parse error | Response is not the expected [{date, value}] shape | Adjust the endpoint to return the documented shape |
The categorised error model makes the next step obvious. Failure copy includes the specific row or header that triggered the error so the operator can fix the underlying issue without ZopDev support.
How to set it up and use it day to day
Setup takes 3 to 10 minutes depending on the ingest path.
| Step | Action | Where |
|---|---|---|
| 1 | Open Cost Reports | Sidebar → Cost Reports |
| 2 | Pick a chip | Chip row above the chart (MAU / DAU / API Requests / Transactions / Signups) or “Manage metrics” for custom |
| 3 | Configure ingest | Choose CSV (drag-and-drop) or Pull (URL + auth) |
| 4 | Test Fetch (if Pull) | Validates synchronously; resolve errors |
| 5 | Save | Metric appears as a chip; click to overlay; click again to remove |
For ongoing use, the chips persist across sessions. The most-pinned metric becomes the operator’s default view; switching to a different denominator is one click.
Three patterns work especially well in the first 90 days:
| Pattern | Why it works |
|---|---|
| Start with MAU + API Requests | Two denominators cover the most common cost driver: human users + machine traffic |
| Switch from CSV to Pull after 2 weeks | CSV verifies the chart shape; Pull keeps it fresh |
| Compare per-MAU across quarters | Year-over-year improvement is the cleanest signal of infra leverage |
The cost number alone has been the FinOps conversation for years; it has not been enough. Cost per unit is the conversation that travels to the board, to the product team, to the investors. The overlay is the surface that makes the per-unit number a regular view rather than a quarterly spreadsheet. Pin a denominator. Watch the secondary axis. Decide whether to celebrate or to start the right-sizing conversation. That is the work the work is for.
