← Back to Blog

I Thought I Was Paying £1,200 for App Insights. I Wasn't Paying for It at All.

Paul Allington 26 June 2026 8 min read

I opened the session genuinely cross. I'd been staring at a cost breakdown for one of my subscriptions and there it was, plain as day: about £1,200 going somewhere near Application Insights. Twelve hundred quid. For telemetry. I typed the message in the tone of a man who already knows he's been robbed: "apparently I'm paying about £1200 for App Insights — can you find out how on earth??"

Here's the thing though. I was wrong about almost every word of that sentence except "£1200" and "how on earth". I wasn't paying £1,200 for App Insights. I wasn't paying for App Insights at all, really. And the actual money was hiding somewhere I'd never have thought to look, behind a setting I didn't remember switching on. This is the story of how the AI found it — and, more interestingly, why it found it instead of just agreeing with me.

The textbook answer, which was completely useless

The first thing the AI did was the thing any competent engineer would do. Application Insights is billed on data ingested — gigabytes in, money out. So it went and measured ingestion across every Application Insights component in the subscription. All thirty-two of them.

The total, across thirty days, was about 0.06 GB.

Sixty megabytes. That's pennies. That is not a number that turns into £1,200 unless Azure has started charging by the byte in a currency I've never heard of. And this is the moment I want to dwell on, because it's the whole post really: the AI's correct, textbook, by-the-book answer proved that my premise was nonsense. The cost driver it was told to investigate could not possibly account for the bill I was angry about.

A lesser version of this — and I've seen plenty of them — would have nodded along. "Yes Paul, App Insights ingestion can be expensive, here are five tips to reduce your telemetry volume." All true. All completely beside the point. The bill was real and the explanation was wrong, and the only way to find out was to stop trusting the label.

Following the actual money

So it threw out my framing and went to the source of truth: Azure Cost Management, the authoritative breakdown for the month. Total spend, roughly £3,915. And then the punchline.

There was no Application Insights line item. None. The ~£1,200 I'd been shaking my fist at was Azure App Service — an expensive plan, doing expensive App Service things. The thing I'd mentally filed as "monitoring overhead" was just compute, sitting in a category my eye had skated straight past. Separately, there was about £600 of Log Analytics, which is a different beast wearing similar clothes.

I'll be honest with you, this is embarrassing to admit in writing. I have been doing this for nearly two decades. And I still looked at a cost breakdown, saw a big number near a word I associated with monitoring, and built an entire grievance on top of it. The line item you're angry about is almost never the one you're actually paying.

The £600 firehose

With the premise demolished, it went after the real money properly — the £600 of Log Analytics, because that's where the genuine waste tends to hide.

One Log Analytics workspace was ingesting around 419 GB a month. Of that, about 347 GB was a single category innocuously named AzureDiagnostics. That's the kind of name that makes your eyes glaze over, which is presumably why it had been quietly costing money for ages without anyone noticing.

The AI drilled into it and found the culprit: one diagnostic setting, on one Cosmos DB for MongoDB (vCore) cluster, logging the per-request category. One toggle. It was producing roughly 74 million rows in seven days — call it 294 GB a month, somewhere around £600 a month — to record, in exhaustive detail, every single request the database had ever served. Nobody was reading these logs. Nobody had ever read these logs. They existed because a checkbox got ticked once, probably by me, probably while I was trying to debug something entirely unrelated.

The fix was almost insultingly small. Disable that one log category. Keep the near-zero-cost metrics, which are the bit you actually want. One setting off, £600 a month gone. No code change, no redeploy, no architecture review. Just a checkbox that should never have been ticked.

The bill that wasn't even mine

Then it found the second leak, and this one was structural rather than careless.

About fifteen Application Insights components that belonged to a separate account were workspace-bound to the default Log Analytics workspaces in my subscription. Which meant their telemetry was landing in my workspaces and being billed to me. Not maliciously, just the default behaviour of components that were created without anyone specifying where their data should live, so Azure shrugged and used the nearest default. Mine.

The AI repatriated all fifteen of them to their own workspace, where their costs belonged. Then it did the sensible defensive thing and set a 1 GB/day cap on the workspaces as a guardrail — so that if anything ever starts firehosing again, it hits a ceiling instead of a credit card. Defaults are where money quietly leaks, because nobody chose them on purpose. A default workspace is exactly the kind of decision that gets made by no one and paid for by you.

The toggles nobody remembers switching on

Once you start seeing the cloud this way — as a building full of light switches, half of them billed by the hour — you start finding them everywhere. A couple from the same week that have stayed with me.

The SFTP-on-storage feature. Azure charges you roughly £0.30 an hour simply for having it enabled. Not per transfer. Per hour, for existing. That's about £114 a month for a feature you switched on once to move some files and then forgot about entirely. It doesn't show up as "SFTP" on a bill in any way that makes you suspicious. It's just a small constant hum of money leaving, billed by the hour, for a thing that's switched on. Per-hour feature toggles are the silent budget killers — the meter runs whether you use the thing or not.

And then my favourite, because it's a story about the AI catching itself. On a separate job — right-sizing some VMs — it was pulling Azure metrics to see how hard the machines were actually working. Halfway through, it stopped and flagged a bug. In its own work. It had been running the metrics queries without an --end-time flag, and Azure had silently been capping every single query to the first hour of available data. Every conclusion it had drawn so far was based on sixty minutes of cherry-picked history.

It fixed the flag, re-ran the queries against the full window, and the picture changed completely. One VM was peaking at about 25.5 GB of RAM — which looks like a machine under real pressure, until you line the peaks up against the clock and realise they're all happening overnight. It wasn't users. It was batch jobs grinding away at 3am. During the actual working day the thing was half asleep, which meant it could safely come down a tier. The number that looks like load is often just the night shift.

What I actually learned, beyond the £600

The money is nice. Knocking £600 a month off a Log Analytics bill and repatriating fifteen components' worth of someone else's telemetry is a good afternoon's work in anyone's book. But that's not the bit that stuck.

What stuck is that cloud bills lie to your intuition, systematically and by design. The expensive-looking word isn't the expensive thing. The category you ignore because it's called AzureDiagnostics is the one eating your budget. The feature you'll never spot on an invoice is billing you by the hour for the privilege of being switched on. Your eye is drawn to exactly the wrong place, every single time, and no amount of experience seems to fully cure it — I'm living proof.

AI turns out to be genuinely, almost suspiciously good at this particular kind of work. Not because it's clever, exactly, but because the job is a grind: query the metrics, pull the breakdown, drill into the category, find the setting, cross-check against the clock. It's forensic accounting with a CLI, and it never gets bored or decides it's probably fine and goes for a coffee. That's the part nobody writes about — the unglamorous query-the-data-again-from-a-different-angle grind is exactly where this stuff earns its keep.

But — and this is the only bit that really matters — it was only useful this time because it was willing to disprove my premise before confirming it. I handed it a confident, wrong assumption ("I'm paying £1,200 for App Insights") and it went and measured the thing I'd accused, found the numbers didn't add up, and told me I was wrong before it told me anything else. If it had simply agreed with me and started "optimising" my Application Insights ingestion, I'd have spent an afternoon shaving pennies off the wrong service while the real £600 carried on firehosing into a workspace I wasn't even looking at.

So here's the practical bit, if you're staring at a cloud bill that's making you cross. Don't optimise the line item you're angry about. Go to the actual cost breakdown — the authoritative one, not your memory of it — and follow the biggest number wherever it genuinely leads, even if that's somewhere boring and badly named. Check what's billed by the hour just for existing. And if you're handing the job to an AI, make sure it's the kind that'll tell you your premise is rubbish, because the most useful thing mine did all day was disagree with me in the first five minutes.

Want to talk?

If you're on a similar AI journey or want to discuss what I've learned, get in touch.

Get In Touch

Ready To Get To Work?

I'm ready to get stuck in whenever you are...it all starts with an email

...oh, and tea!

paul@thecodeguy.co.uk