🔧KQL Tools

KQL Cost Query Builder

Ready-to-use KQL queries for Azure Log Analytics cost analysis. Customise the parameters and copy directly into Log Analytics.

monitor_heartModel ingestion costs in Log Analytics calculator

ℹ️

These queries run in your own Azure Log Analytics workspace. Copy the query and paste it into Azure Portal → Log Analytics → Logs to run it against your data. AzureCalc.uk does not connect to your Azure subscription.

Ingestion by Resource Group

Aggregate billable ingestion and estimated cost by Azure resource group. Useful for team chargeback and showback.

KQL

let CostPerGB = 2.167;
let TimeRange = 30d;
let CurrencySymbol = "£";
find where TimeGenerated between(startofday(ago(TimeRange)) .. startofday(now()))
    project _ResourceId, _BilledSize, _IsBillable
| where _IsBillable == true
| summarize BillableDataBytes = sum(_BilledSize) by _ResourceId
| extend ResourceGroup = tostring(split(_ResourceId, "/")[4])
| summarize BillableDataBytes = sum(BillableDataBytes) by ResourceGroup
| extend DataIngestedInGB = round(BillableDataBytes / 1e9, 2)
| extend Cost = strcat(CurrencySymbol, round(DataIngestedInGB * CostPerGB, 2))
| project-away BillableDataBytes
| sort by DataIngestedInGB desc

Lines 1–3: Variables

Edit these in the panel on the right. CostPerGB is your PAYG ingestion rate. These let-bindings make the query easy to customise.

Line 4: find operator

Scans ALL tables in the workspace for matching rows. Note: this can be resource-intensive on large workspaces with many tables.

Lines 5–6: Billable filter

_IsBillable filters to only data you are charged for. Free tables like Heartbeat and AzureActivity are excluded from the cost total.

Lines 7–8: Resource group extraction

Extracts the resource group name from the ARM resource ID string (segment at position [4] in the "/" split).

Lines 9–10: Bytes to GB

Converts bytes to GB using Azure's billing standard (10⁹ bytes = 1 GB, not 1 GiB = 1,073,741,824 bytes).

Lines 11–12: Cost & tidy

Formats the cost as a currency string. project-away removes the raw bytes column — only GB and cost are shown in results.

open_in_newOpen Azure Log Analytics demo workspace

Global Parameters

Time Range

Cost per GB (£/GB)

Currency Symbol

Query Parameters

Filter by resource group (optional) (optional)

Active Values

TimeRange30d

CostPerGB2.167

CurrencySymbol"£"

calculateLog Analytics Cost Calculator →✨Guided Cost Estimator →

Operational Guidance

How to use these KQL cost queries safely and interpret the results

This page is more than a code snippet library. The queries exist to help teams understand how Log Analytics usage translates into cost drivers such as ingestion, table mix, noisy resources, and historic search behavior. The value is not just in copying a query, but in knowing what question it answers and how to validate the output before changing architecture or budget assumptions.

AzureCalc.uk does not connect to your subscription. The queries run in your own workspace, which is useful from a security standpoint, but it also means you need to interpret the results in the context of your own retention settings, access patterns, and table design.

Why these queries exist

Each query is designed to answer a practical FinOps or operations question. Which resource groups are generating the most billable data? Which tables are consuming the budget? How does a selected time range change the estimated spend profile? Those are decisions teams need when they are controlling telemetry growth rather than merely inspecting logs.

The builder adds parameters so you can adapt each template without manually rewriting KQL syntax every time. That makes it easier to compare scenarios while still keeping the query logic transparent.

How to use the queries safely

Run them first in the right workspace and time range so you do not overgeneralise from the wrong dataset.
Check the selected pricing assumption before presenting a cost figure as a real forecast.
Validate any custom filters, especially resource group or table parameters, so you do not accidentally narrow away the main source of spend.
Treat the results as a decision aid, not a replacement for invoice review or Azure Cost Management.
Sanity-check unusually large or small outputs against known ingestion spikes, incidents, or onboarding events.

How to interpret what the output is telling you

A high-cost table is not automatically a problem. It may reflect valuable security or platform telemetry. The important question is whether the data volume aligns with operational value. Likewise, a low-cost result is not automatically healthy if it is caused by short retention or incomplete ingestion.

Good interpretation means comparing the query result with the service purpose. If a single resource group dominates spend, ask whether that is expected. If a table grows rapidly, determine whether the increase was caused by a feature rollout, a noisy data source, or a temporary incident.

Worked example: from noisy table to action

Suppose a query shows that one table is responsible for a disproportionate share of billable ingestion over the last 30 days. The next step is not to delete the data blindly. It is to identify the source, determine whether the records are operationally necessary, and then decide whether filtering, plan changes, or retention adjustments are safer interventions.

Used properly, these queries support a measured workflow: identify the cost driver, verify the technical reason, then make a targeted change rather than a blanket cut.

Where this fits in the wider AzureCalc workflow

The KQL Builder complements the Log Analytics calculators rather than replacing them. Use the calculators when you need a planning estimate and use these queries when you need to validate what is happening inside a live workspace. Together they give you both prospective and diagnostic views of observability cost.

That pairing is also important for content quality: this page is useful because it explains why the templates matter, not because it pads out a code tool with generic filler.

Methodology

The default cost assumptions on this page are aligned to the broader AzureCalc.uk pricing methodology, but the final result still depends on your workspace, your selected filters, and the Azure pricing context you apply. Use the methodology page when you need provenance for the reference numbers shown here.

Review methodology and provenance →

arrow_forwardLog Analytics Calculator arrow_forwardLog Analytics Pricing Guide arrow_forwardSearch Job vs Restore arrow_forwardFAQ