The bill went up. Nobody can say what it bought.

Cost and reliability are the same conversation

On Azure they usually are. Over-provisioning is the standard response to a performance complaint nobody diagnosed, so a rising bill is often the visible symptom of an undiagnosed constraint rather than a spending problem. Cutting the spend without finding the constraint gives you a slower system and the same complaint.

This review is the same thing the rest of our work sells, applied to Azure: measure first, name the layer that owns the problem, and change one thing at a time with an owner and a way back.

What brings people here

1. /01

   The bill went up and nobody can explain it

   What is the spend actually buying, and which of it is load rather than waste?

   An Azure bill is a sum of decisions, most of them made under time pressure and few of them written down. The review separates resources carrying real load from resources that were scaled during an incident and never scaled back, orphaned disks and snapshots, and tiers chosen before anybody measured the workload.

2. /02

   Somebody resized it and nothing got faster

   Is the constraint compute, storage, network — or the query plan underneath?

   Adding vCores is the most common response to a slow system and the most common wasted spend. If the constraint is storage latency while posting and reporting overlap, a larger SKU is an expensive way to wait. Measuring which layer owns it costs a fraction of a tier upgrade.

3. /03

   Nobody has tested the recovery

   How long does a restore actually take, and who has done it?

   Azure Backup being green is not the same as a restore somebody has run, timed and watched. The review establishes what the real recovery time is, whether the runbook assumes a person who still works there, and what the business loses per hour while it runs.

4. /04

   The alerts are ignored

   Which of these alerts has anybody acted on in the last month?

   Azure Monitor will happily generate more signal than a small team can read. The useful exercise is to sort a month of alerts into the ones somebody acted on and the ones somebody acknowledged — then give the second pile a threshold that would move it, or stop sending it.

What is in scope

• Azure SQL, Managed Instance and SQL on VMs. Service tier and sizing against measured workload, storage latency, backup configuration and tested recovery time.
• Business Central on Azure. Where the estate is on-premises or hosted on Azure infrastructure, the service tier and the database beneath it. Business Central online is a different conversation — see the note below.
• Azure Database for PostgreSQL and MySQL. Tier, storage and IOPS against real usage, connection handling, and the maintenance settings that decide whether a busy period degrades.
• The platform underneath. Disks and their performance tiers, orphaned resources, network paths that add latency to a workload, and the reserved-capacity decisions nobody revisited.
• Observability and recovery. What is actually measured, what is only alerted on, what a restore takes in practice, and who owns each of those answers.

How it runs

1. The free half hour. Describe the estate and what hurts. You get an honest read on the spot, including when the answer is that you do not need us.
2. Agree the scope in writing. Which subscriptions and resources, what access, what the deliverable is, and the fixed fee. Nothing starts before that is signed.
3. Collect read-only. Portal and metric exports, and queries your own team can read. No write access, no agent left behind, no production change.
4. Hand over the evidence. A ranked assessment with the signal behind each finding, what is still unmeasured, and what to verify before changing anything. Implementation is scoped separately.

Questions people ask about Azure spend

Why did our Azure bill go up when nothing changed?

Usually something did change, just not deliberately. The common causes are a resource scaled up during an incident and never scaled back, storage that grew past a tier boundary, a backup retention setting nobody revisited, and orphaned disks or snapshots from machines that were deleted. None of them appears as an event. All of them appear on the invoice.

Will moving to a bigger Azure SQL tier fix our performance problem?

Sometimes, and often not. If the constraint is storage latency, a missing index, or a query plan that changed, a larger tier buys you a more expensive version of the same wait. The honest order is to measure which layer owns the problem, then resize only if the measurement says to. That order routinely costs less than one month of the upgrade.

Can you tune Business Central online on Azure?

Not at the database layer — nobody can, including Microsoft partners. In Business Central online the SQL Server is not reachable by anyone. What is reachable is AL code, telemetry in Application Insights, and how extensions and integrations are written. If your estate is on-premises or hosted on your own Azure infrastructure, the database is in scope. We will tell you plainly which case you are in.

Do you need production access, or admin rights on our tenant?

Read-only, inside a scope agreed in writing, and no write access at any point. Where possible the collection runs as queries and portal exports your own team can read and run themselves. You keep everything produced.

Is this a managed service?

No. It is a review that ends in a document: what the evidence says, what it does not say, and a ranked list of what to do about it. Implementation is scoped separately, and we will say when the honest answer is that the work does not need us.

Related

• Database performance investigation — when the symptom is speed rather than spend.
• Dynamics NAV to Business Central — when the estate is also on a support deadline.
• On-premises data to cloud migration — when the question is whether to move at all.

Findings depend on the evidence available. We do not promise a cost reduction, a performance gain or a recovery time before assessment, and a recommendation is not permission to change production. Please do not send credentials, production data or confidential files through the introductory form or chat.