Cloud waste isn't a failure of engineering discipline. It's what happens when creating a resource takes a minute and remembering it takes a person. Chronom reads utilization across every subscription, claims the licensing rights most teams never apply, and puts guardrails behind the fix so the estate doesn't refill.
A SKU sized for a peak that utilization data shows never arrives just sits there looking normal. No incident, no ticket, no owner - only a line item that reads the same every month.
Dev, test and sandbox subscriptions run around the clock to serve a working week. Auto-shutdown has been on the backlog since the quarter it was created, behind everything customer-facing.
Windows Server and SQL Server licenses with Software Assurance, dev/test rates, free Extended Security Updates in Azure. Eligibility is contractual, so nothing in the console warns you it's going unused.
Three levers, in a fixed order: stop paying for what nothing uses, put the estate in the right shape, then claim the entitlements and commitments that price it. Reverse the order and you lock the waste in.
A stopped VM in Azure isn't a deallocated one - it keeps reserving and billing compute until you deallocate it. An unattached managed disk bills at full rate forever. Reserved public IPs, idle Application Gateways, VPN and NAT gateways, Bastion hosts and migration-era snapshots all keep charging with nothing pointed at them.
Individually each is too small to escalate. That's precisely why this bucket is usually 10–20% of the bill.
Typical split: 10–20% waste · up to 65% off non-prod · up to 40% on eligible compute
Azure Hybrid Benefit lets you run Windows Server and SQL Server on licenses you already own with Software Assurance instead of paying Azure for them again. Dev/test subscriptions carry lower rates for non-production. Extended Security Updates are free in Azure for eligible workloads. Azure SQL on the wrong model - DTU where vCore is cheaper, provisioned where serverless fits, single databases that belong in an elastic pool - is a billing choice, not an architecture one.
All of it depends on rights in your agreement rather than switches in the console, which is exactly why the portal never mentions you're eligible.
Reservations and savings plans are a purchasing decision, and they price whatever shape you commit at for one to three years. Reserve an oversized VM and you've locked the waste in with a discount attached to it.
Right-size first, then read coverage and utilization together: steady workloads still on on-demand rates, and reservations already bought sitting unused at the wrong scope.
Unattached disks, undeallocated VMs, orphaned IPs and NICs, idle gateways, stale snapshots. Dependency-checked first, but nothing here is a trade-off.
45 working hours against 168 billed. Build the schedule from real start-stop and pipeline activity, with overnight jobs excluded by name.
Not against the peak somebody sized for at migration. CPU, memory, IOPS and connection data decide the SKU.
Azure Hybrid Benefit, dev/test rates, free Extended Security Updates, the right Azure SQL edition and billing model. Paperwork, not re-architecture.
Log Analytics retention set per table against what's genuinely queried, Sentinel commitment tiers matched to volume, Blob on the access tier and redundancy the data actually needs.
Buy reservations and savings plans against the corrected shape. Then tagging, budgets and anomaly detection, so the estate doesn't refill by the next quarter.
Examples rather than the catalogue - a sample of what the platform reads across your subscriptions, resources and meters, ranked by annual dollars.
Cloud waste isn't a failure of engineering discipline - it's the natural end state of every environment where creating a resource takes a minute and remembering it takes a person. Add the licensing rights most teams never claim, and the gap gets wide.
Unattached managed disks, VMs stopped but never deallocated, orphaned public IPs and NICs, idle Application Gateways, VPN gateways, NAT gateways and Bastion hosts, snapshot sets from a migration two years ago, empty AKS node pools and App Service plans.
Each one is individually too small to notice. Together they're a headcount.
Dev, test and sandbox subscriptions on 24/7 compute to serve a 45-hour working week. Plus VM SKUs sized for a peak that 30 to 90 days of utilization data shows never arrives.
Nothing breaks when a resource is oversized, so nothing escalates. The bill just sits there looking normal.
Azure Hybrid Benefit for Windows Server and SQL Server licenses you already own with Software Assurance, dev/test subscription rates for non-production, and Extended Security Updates that are free for eligible workloads in Azure.
These are contract rights, not console settings. The portal will never tell you you're eligible.
Azure SQL on DTU where vCore is cheaper, provisioned where serverless fits the traffic pattern, dozens of small databases that belong in an elastic pool, App Service plans that should be consolidated, and AKS node pools with no spot or burstable mix.
The migration picked a model years ago. Once it works, nobody revisits whether it's the cheapest way to run it.
Log Analytics ingestion broken out by table, Sentinel commitment tiers against actual volume, retention set by what's genuinely queried, and Blob storage on the wrong access tier or carrying geo-redundancy nothing requires.
Log and telemetry spend grows quietly with the estate, and almost nobody reviews it line by line.
Every change is dependency-aware before it's proposed. Tagging, budgets and policy go in behind it, and anomaly detection flags a new meter or a new resource class within a day of it appearing.
Month-end close is the worst possible moment to find out about a resource somebody spun up on the 3rd.
Changes are dependency-aware before they're proposed and scheduled around the environments that matter. Guardrails and tagging go in behind them so the estate doesn't refill, and anomaly detection flags new drift within a day instead of at month-end close. The same reads run against AWS - EC2, EBS, RDS and S3 - for estates that span both clouds.
Figures on this page describe an illustrative $1.8M Azure estate, shown for illustration. Your audit replaces them with your own numbers, tied to named subscriptions, resources and meters.
Every cloud finding arrives as a decision with the dependency check already done, the environment identified, and the annual value attached.
Utilization shows a 45-hour working week and peaks well below the current SKU. Nightly builds and long-running tests are excluded by name; production is out of scope.
Licenses with Software Assurance already owned and verified against your agreement. No re-architecture, no downtime, no change a user could notice.
Stopped is not deallocated in Azure. Disks and configuration are preserved exactly as they are, so the VM starts again unchanged.
No VM attachment and no restore reference. Snapshots older than your retention standard are exported first wherever anyone still needs them.
Retention set per table against what's actually queried, with compliance-relevant tables kept at full retention in the archive tier.
Network path confirmed unused and every dependency checked before anything is deleted.
Every line in a Chronom report is a decision with an owner, a SKU and a dollar figure. Nothing is left for you to go and find out.
“Low Teams usage detected” - a fact you now have to interpret
An alert queue that grows faster than you can triage it
A dashboard that hands the analysis back to you
A one-off clean-up decays within a quarter: a new environment appears, a resource gets resized for a load test and left there, a meter starts on the 3rd. Chronom keeps reading so the next month's bill doesn't surprise anyone.
Every scan compares the estate against the baseline you approved. A new unattached disk, an untagged resource group or a fresh meter surfaces within a day rather than at month-end close.
Reserving a workload at today's oversized shape locks the waste in for one to three years, so the sequence is always resize first, then commit - with the coverage decision fed by the corrected shape.
Ownership and environment tags are enforced behind the cleanup, so the next orphaned resource has a team name attached to it instead of becoming somebody's archaeology project.
Spend anomalies are detected against pattern rather than against a static budget, which is what catches a runaway meter in the week it starts.
It's reducing what an Azure estate costs to run without reducing what it does, and the savings arrive in three distinct buckets. First, waste: unattached disks, stopped-but-not-deallocated VMs, idle gateways and orphaned IPs, which is typically 10–20% of the bill. Second, shape: shutdown schedules for non-production and right-sizing against real utilization, worth up to 65% on non-prod compute. Third, entitlements: Azure Hybrid Benefit, dev/test subscription rates, free Extended Security Updates in Azure and the right database billing model, worth up to 40% on eligible compute. Reservations and savings plans come after all three, never before.
Advisor and cost analysis surface signals inside one subscription's console and leave the analysis, the dependency checks and the licensing questions to you. Chronom reads across every subscription at once, ranks findings by annual dollars, checks dependencies before anything is proposed, and includes the contractual levers no console knows about - Azure Hybrid Benefit, dev/test rates, Extended Security Updates, database billing models. Then, if you want, our team executes the changes rather than handing you a backlog.
Analysis is read-only by construction - the scan reads utilization, metadata and billing data, and nothing in the estate moves. Execution is opt-in and sequenced: dependency-aware, scheduled around the environments that matter, and never without your approval. Guardrails and tagging go in behind each change so the same waste can't quietly rebuild.
For eligible Windows Server and SQL Server workloads it's worth up to 40% on the compute you're already running, because you stop paying Azure for a license you own. Eligibility depends on your Software Assurance and subscription entitlements rather than anything visible in the portal, which is exactly why it goes unclaimed - so we check the rights in your agreement, count the VMs that qualify, and price the gap before recommending the change.
Not when the schedule is built from how the environments are actually used. We read start-stop patterns, pipeline windows and connection activity per environment, then propose schedules with explicit exclusions for anything that legitimately runs overnight - nightly builds, long-running tests, shared services. Production is never in scope for a shutdown recommendation.
Yes. The same reads run against AWS - EC2 right-sizing and schedules, unattached EBS volumes and stale snapshots, idle load balancers and elastic IPs, RDS instance shape and S3 storage classes - which matters for the many Microsoft-centric estates that also carry an AWS footprint. Chronom is listed on both the Azure and AWS marketplaces.
They come after right-sizing, because they're a purchasing decision rather than an engineering one - and because right-sizing first changes what you should commit to. The sequence matters: reserve a workload at today's oversized shape and you've locked in the waste for one to three years. Once the estate is the right shape, we read coverage and utilization together - steady workloads still paying on-demand rates, and reservations already bought that sit unused at the wrong scope.
Get a comprehensive audit of your environment and see exactly how much you can save in under 15 minutes.