DEV Community: HosheBartar

Which resource or meter carries your Azure cost? A group-and-compare check you can do by hand

HosheBartar — Sun, 15 Nov 2026 15:12:21 +0000

"Azure SQL Database went up" is a start, not an answer. Which database? And was it compute hours or stored data? The service view of your bill cannot say, because it is the wrong grouping for that question.

Most cost questions are answered by the same move: pick the grouping that matches the question, list every item, and compare each one with the period just before. You can do it with Cost analysis and a spreadsheet.

Step 1: pick the grouping that fits the question

In the Azure portal, open Cost Management > Cost analysis on the subscription or billing scope, and use Group by:

Service name: which product family costs most. Good for a first look.
Resource group name: which environment or team, if your groups follow them.
Resource: which single database, app or storage account.
Meter: what you are billed for inside a service: compute hours, stored data, operations, data transfer. Several resources can share one meter.
Subscription: only useful on a scope that holds more than one.

A rule of thumb: go one level down from where the surprise showed up. A service grew? Group by resource, then by meter.

Step 2: export two equal periods

Set the date range to the last 30 complete days. Azure publishes cost a day or two late, so leave the newest day or two out.
Download the grouped view as CSV.
Do the same for the 30 days just before, with the same grouping and the same scope.

The two periods must have the same number of days, or every change you compute is skewed.

Step 3: join them and compute four columns

Put both exports in one sheet, joined on the item name (XLOOKUP or a pivot table works). For each item compute:

Cost in the recent period.
Share: cost divided by the total of the list. Take the total from the same export, not from another screen, so shares and costs cannot disagree.
Previous period: the cost in the earlier 30 days.
Change: recent minus previous, in money, and as a percentage of the previous cost.

Sort by cost, largest first.

Step 4: keep the rows people drop

Three kinds of rows usually fall out of a hand-made comparison, and they are often the interesting ones:

New items: a cost now, nothing before. A percentage makes no sense here (there is nothing to divide by), so label them "New" instead of showing a huge number.
Gone items: a cost before, nothing now. A lookup from the recent list never finds them. List them separately; they explain part of a falling total, and they confirm that a cleanup really happened.
Items without a name: some cost is recorded against the subscription itself, not a resource group or a resource. A reservation purchase or a support plan are typical. Keep them as rows of their own, or your list no longer adds up to the invoice.

Step 5: read the list

A large share with a small change is your baseline. It matters for architecture decisions, not for this month's surprise.
A small share with a large change is where to look first. The same resource grouped by meter then says whether compute, storage or traffic moved.
Do not colour rises red and falls green. A rise can be planned growth, and a fall can be an outage.
If the scope is billed in two currencies, do one sheet per currency. Adding them without an exchange rate gives a number that means nothing.

Doing it without the spreadsheet

The steps above are worth doing once by hand. Repeating them for every question is the tedious part.

(I build CostGuard, an Azure cost tool on Azure Marketplace with a Free plan, so weigh this accordingly.) Its Cost Explorer page does this for the scope you pick: you choose service, resource group, resource, meter or subscription, and it lists every item with its cost, its share, its cost in the same number of days before and its change. Items with no cost before are marked "New", items billed only in the days before are named under the list, and cost without a resource group or a resource keeps a row of its own.

It only reads cost: the connection uses the built-in Reader role, so it cannot change anything in your Azure.

Honest limits

Cost data arrives a day or two late, by hand or in any tool, so a range that ends today is not final.
A comparison says what moved, not why. Someone still has to know that the new replica was planned.
CostGuard holds no exchange rates: each currency is listed on its own and nothing is converted.
Cost Explorer is on the Starter plan and up; the Free plan shows a labelled sample of the page.

The full walkthrough of the page: https://hoshebartar.com/en/help/cost-explorer?utm_source=devto&utm_medium=article&utm_campaign=kb-cost-explorer

Which grouping do you reach for first when an Azure bill surprises you: service, resource group, resource or meter?

Is your Azure cost a spike, a step or just the week's rhythm? A day-of-week check you can do by hand

HosheBartar — Sun, 08 Nov 2026 15:18:02 +0000

The invoice says the month cost more. The daily chart in Cost analysis looks busy. Before anyone starts deleting resources, it helps to know which of three shapes you are looking at:

A spike: one tall day, then back to normal. Usually a batch job, a data load, a load test or a one-off purchase.
A step: the line moves up and stays up. Usually new or larger infrastructure: a scaled-up SKU, a new environment, a replica nobody removed.
A rhythm: a regular dip every few days. Usually resources that run on office hours, and the dips are the quiet days.

They need different responses, and you can tell them apart with a Cost analysis export and a spreadsheet in about fifteen minutes.

Step 1: export daily cost for two periods

In the Azure portal, open Cost Management > Cost analysis on the subscription (or the billing scope you care about).

Choose the Daily costs view, or set granularity to Daily in the accumulated view.
Set the date range to the last 28 complete days. Azure publishes cost a day or two after it is incurred, so leave the most recent day or two out; they are not final.
Download the view as CSV.
Repeat for the 28 days just before.

28 days is deliberate: it holds every day of the week exactly four times, so no weekday is over-represented.

Step 2: overlay the two periods

Put both periods side by side, day 1 next to day 1, and chart them as two lines on one axis that starts at zero. An axis that starts at the lowest value makes a 5% wobble look like a cliff.

Now read the shape:

One point far above both lines: a spike. Find the date, then group that one day by Service name or Resource in Cost analysis to see what ran.
The current line runs at the old level, then jumps and stays higher until the end: a step. Note the first high day; the change was made then. Group the days after it by resource group or resource and compare them with the days before.
Both lines go up and down together on the same weekdays: a rhythm, and the next step measures it.

Step 3: average by day of the week

Add a column with the weekday of each date (=TEXT(A2,"dddd") in Excel or Google Sheets), then average the cost per weekday with a pivot table or AVERAGEIF.

Two rules keep this honest:

Average only the days that have a cost record. A missing day in the export is not a free day; Azure may not have delivered it yet. Count the days behind each average and show the count.
Compare averages, not totals, when the two periods have a different number of recorded days.

What the result tells you:

A clear gap between working days and the rest usually comes from resources that run on office hours, or from workloads driven by your users' working week.
A flat week comes from resources that run all the time. That is normal for production. If development and test resources are just as expensive on quiet days, they are candidates for an auto-shutdown schedule or for scaling down outside working hours.

Do not label any day a "weekend" in a shared sheet: which days are quiet depends on where your team and your customers are.

Step 4: month by month, by average day

If your range crosses months, compare months by average cost per recorded day, not by total. A month you only cover in part (say 12 days of 15) would otherwise look cheaper than it was.

Doing it on every refresh

The steps above are worth doing once by hand, so you know what you are looking at. Repeating them every week is where it gets tedious.

(I build CostGuard, an Azure cost tool on Azure Marketplace with a Free plan, so weigh this accordingly.) Its Cost trend page does this for the scope you pick: the daily line laid over the period just before on an axis from zero, the daily average and its change, the highest, lowest and latest recorded day, the average by day of the week once the range covers 14 days, and a month-by-month table that marks partial months.

It only reads cost: the connection uses the built-in Reader role, so it cannot change anything in your Azure.

Honest limits

Cost data arrives a day or two late, by hand or in any tool; the newest days can still change.
The day-of-week average says when cost is higher, not why. You still group by service or resource to find the cause.
CostGuard holds no exchange rates, so a scope billed in two currencies is read one currency at a time.
Cost trend is on the Starter plan and up; the Free plan shows a labelled sample of the page.

The full walkthrough of the page, figure by figure: https://hoshebartar.com/en/help/cost-trend?utm_source=devto&utm_medium=article&utm_campaign=kb-cost-trend

How do you read your daily Azure cost: a dashboard, a weekly export, or only when the invoice arrives?

Where is this month's Azure cost heading? A month-end estimate you can do by hand

HosheBartar — Sun, 01 Nov 2026 17:34:20 +0000

Halfway through the month, someone asks: "Where will we land?" The invoice will not tell you for weeks, and Cost Management's built-in forecast is a line on a chart that is hard to explain to a team. Here is a month-end estimate you can do by hand in a spreadsheet, explain in one sentence, and check against your budget. Then how we automated it.

1. Get the recorded daily cost

In the Azure portal, open Cost Management > Cost analysis for the subscription, choose the Daily costs view for the current month, and download it as CSV. You now have one row per day with its cost.

Two things to know before you use it:

Cost arrives a day or two late. The last day or two in the file are usually incomplete. Find the latest day you trust; call it the latest recorded day. Everything after it is "remaining".
Keep one currency. If your scope is billed in more than one currency, do the estimate per currency. Adding USD and EUR without a rate gives a number that means nothing.

2. Average the latest seven days

Take the latest seven days with recorded cost and average them. Seven days covers a full week, so weekend dips and weekday peaks cancel out. If the month has fewer than seven recorded days, average what you have.

Example: the latest seven days cost 120, 118, 131, 125, 90, 88, 128. The average is 114.29 a day.

3. Add a trend once you have two weeks

With 14 or more recorded days, compare the average of the latest seven days with the average of the seven before them. If the earlier week averaged 107.14, the daily cost rose by about 7.14 a week, or about 1.02 a day. Add that daily step to each day ahead: day one is 115.31, day two 116.33, and so on. Never let a day go below zero.

Without a trend, a cost that is climbing steadily is underestimated every time.

4. Add up the month

Recorded so far: the sum of the recorded days this month.
Forecast for the remaining days: the sum of your forecast days, from the day after the latest recorded day to the last day of the month.
Forecast to month end: the two added together.

Then put two numbers next to it:

Your monthly budget, in the same currency: the forecast as a share of it, and how much over or under.
Last month's recorded cost for the same subscriptions: the change as an amount and a percentage.

5. Put a band around it, and say what it is

Add 10% either side of each forecast day and sum again, with the recorded cost in front. That gives a low and a high month-end figure. Be clear with your team about what this is: not a probability, and not a confidence interval. It shows how far a 10% miss on every remaining day would move the month. Early in the month the band is wide, because most of the month is still forecast; near the end it is narrow.

The automated way

(I build CostGuard, an Azure cost tool sold on Azure Marketplace.) Its Forecast overview page automates this on the Pro plan: the cost recorded so far plus a Baseline forecast for the remaining days, made from the latest seven days with a daily trend once fourteen days are recorded, refreshed about once an hour, held against the budget of the scope and against last month.

It also says which subscriptions the forecast covers and which it leaves out, and why, so "Covers 2 of 4 subscriptions in scope" is never hidden inside a total. The day-by-day table shows the recorded days first, then a forecast amount for each remaining day.

Honest limits

It is an estimate from recorded cost, not a bill. The invoice can differ.
A seven-day average does not know about the batch job you plan for the 28th. A one-off spike in the last seven days also inflates it.
The band is fixed at 10% by the method; it does not measure how likely the forecast is.
Amounts in different currencies are never added or compared, and no exchange rate is applied.
In CostGuard, forecasting is a Pro feature; each subscription needs an active Baseline forecast scenario before it is covered. CostGuard only reads your Azure cost; nothing in Azure is changed.

The full walkthrough of the page, figure by figure:
https://hoshebartar.com/en/help/forecast-overview?utm_source=devto&utm_medium=article&utm_campaign=kb-forecast-overview

How do you answer "where will we land this month": the portal forecast, a spreadsheet, or a gut feeling?

Which Azure budget needs action? A pace check you can do by hand

HosheBartar — Sun, 25 Oct 2026 14:15:33 +0000

Azure budget alerts tell you when a budget crosses a share of its amount: 50%, 80%, 100%. That is useful, but a 50% alert on day 25 of the month and a 50% alert on day 6 mean very different things. The second one is a problem; the first one is fine.

Here is a simple pace check you can do by hand for any budget, and then how we automated it.

1. List your budgets and their scopes

In the Azure portal, open Cost Management > Budgets. A budget is set on a scope (a subscription, a resource group, a management group or a billing scope), has an amount and a reset period, and sends alerts on actual or forecasted cost at the thresholds you set. A budget never stops anything: it measures and notifies.

Write down, for each budget: the scope, the amount, the period and the spend so far this period.

2. Compute two shares

For each budget:

Share used = spend so far / amount
Share of the period elapsed = days gone / days in the period

Example: a monthly budget of 1,000, day 12 of 30, spend so far 550.

Share used: 55%
Share of the period elapsed: 40%

The budget is not over, and it may not even have fired its first alert yet if you set it at 80%. But it is spending faster than the calendar: at an even pace it would be at 400, not 550.

3. Grade them

A grading that is easy to explain to a team:

Over: 100% or more of the amount spent.
At risk: 50% or more spent, but not all.
On track: less than 50% spent.
Ahead of pace: share used larger than share of the period elapsed, while the amount is not yet spent.

Sort the list with the worst first, and you know which budget to look at.

4. Keep the traps in mind

Cost arrives late. Azure cost data is usually a day or two behind, so "spend so far" is spend up to a day or two ago.
Currencies. If your subscriptions are billed in different currencies, never add the amounts together without an exchange rate you trust.
Do not prorate the amount. Compare the full amount with the spend so far; the pace check is a separate signal, not a forecast.

The automated way

I build CostGuard, an Azure cost tool for small SaaS teams on Azure Marketplace, and its Budgets page does this check for every budget. (Disclosure: I build CostGuard, so take this part as the maker's description.)

Each budget covers the whole workspace, a subscription, a resource group or a service, per day, week, month, quarter or year (calendar periods in UTC).
The This period column shows the spend, a bar of the share used with a mark at the share of the period elapsed, what remains or by how much it is over, and the day of the period ("Day 12 of 30").
Every budget is graded over, at risk or on track with the 50% and 100% rule above, and "Ahead of the period's pace" is shown when it applies. The list puts the most urgent first.
When no figure can be stated (no cost import yet, cost only in another currency), the row says why instead of showing zero.

CostGuard only reads your Azure data with the Reader role; it never changes anything in Azure.

Honest limits

Email alerts run against one budget only: the enabled monthly budget of the whole workspace. Every other budget shows its usage on the page and raises no alert.
"Ahead of the period's pace" compares two shares; it is not a forecast.
Each budget has one currency, and nothing is converted: cost in another currency is named, not added.
Budgets are on the Starter plan and up (5 on Starter, 20 on Growth, unlimited on Pro). There is a Free plan on Azure Marketplace, where the page shows a labelled sample.

The whole page, section by section: Budgets: see which budget needs action

How to see when your Azure Sponsorship credit will run out

HosheBartar — Fri, 23 Oct 2026 00:20:46 +0000

Azure Sponsorship credit doesn't end with a warning. It lasts until usage consumes the whole grant or until its end date, whichever comes first, and Azure doesn't publish the remaining balance to apps. If your startup runs on it, the useful question isn't "how much is left?" but "on what day does it run out at our current rate, and is that before the end date?"

Here is how to answer that by hand, and how we automated it.

1. Read the balance in the Sponsorships portal

The Azure Sponsorships portal shows the balance, but only to a person who is signed in. There is no app access, so no tool (ours included) can read that number for you.

Two things to keep in mind when you read it:

It is a snapshot. It tells you what is left, not when it will be gone.
Azure reports usage to apps about a day and a half late, so any estimate built from reported usage trails the portal slightly.

2. Work out the run-out day yourself

Three numbers are enough: the grant (its starting amount), the usage so far, and the number of days since the grant's first day.

average per day = used / days since the first day
days left       = (grant - used) / average per day
run-out day     = today + days left

Then compare the run-out day with the grant's end date:

Before the end date: you will start paying before the sponsorship ends. Time to look at what is growing.
After the end date: the grant will expire with credit unused. The unused amount is roughly the remaining credit minus the average per day for each day left until the end date.

A since-start average is simple and stable, but it reacts slowly: a cost jump last week moves the run-out day only a little. Redo the math regularly, and again after any new deployment.

3. Decide when someone should look

The moments that matter are 50%, 75% and 90% used, the day the run-out date moves before the end date, and 30 days before the end date if credit is still left. A spreadsheet and a calendar reminder will do, as long as someone owns them.

The automated way: CostGuard

(I build CostGuard, an Azure cost tool for small SaaS teams, sold on Azure Marketplace.)

Because the balance isn't available to apps, CostGuard estimates it. It reads the usage Azure reports for your connected Sponsored subscriptions from the grant's first day and prices it at the Sponsorship offer's rates. For each grant you track it shows:

the estimated run-out day at the current rate, and whether that is before the end date
estimated used and remaining, and the average use per day
the unused amount expected at the end date, if any

Workspace owners and admins get one alert when a grant reaches 50, 75 or 90% estimated used, is estimated fully used, will run out before its end date at the current rate, or ends within 30 days with credit unused.

Setup takes three steps: record the grant with its starting amount in USD and its end date, choose "Track usage" and enter the sponsorship's first day, then read the grant's outlook after the next check.

Honest limits

It is an estimate, not a balance read from Azure. Because of the reporting lag, the portal can show a little more usage.
Usage that has no Sponsorship price isn't counted, so the estimate can run low.
Only grants recorded in USD are estimated.
It needs only the Reader role on each Sponsored subscription and never changes anything in Azure.
Credit tracking is on the Growth plan and up.

The full walkthrough, with every field and state explained, is in the Azure credits help article.