BC Telemetry Buddy  – When Your 12-Year-Old Accidentally Helps You Find a Problem

TL;DR

While showing my kid what I was working on, I casually asked my BC Telemetry Buddy “what customer has the most reason to complain” – and accidentally discovered a customer bleeding CPU time every morning from a broken background job. The issue got fixed, and this whole thing turned into a nice story to explain how AI can help you in Telemetry “exploration”

The story

So there I was, working on my BC Telemetry Buddy project, when my 12-year-old kid walked into my office and asked: “Really, dad .. ChatGPT again?” (you know – any sort of AI is called “ChatGPT” these days .. at least under my roof .. )

I admit – I was proud of what I was doing – so I wanted to brag a bit .. .  I could have gone into a long explanation about MCP, Azure Application Insights, KQL queries, and all that jazz … but he’s 12. So I went with the coolest possible answer:

“I’m creating an AI.”

BOOM!  Hero!

(Yes, I know I’m not actually creating an AI .. I’m building an MCP that lets you talk to telemetry data using AI .. but you know what? For a 12-year-old, that’s basically the same thing )

He looked interested, so I figured – why not show him? I opened up VSCode with my BC Telemetry Buddy and wanted to demonstrate something cool. But what question to ask?

I decided on something I wondered would work: “What customer has the most reason to complain?”

Now, this was meant to be a fun demo. Something to show the kid how you can just… ask your telemetry stuff instead of writing complex queries.

What I didn’t expect was for the answer to immediately point me to a customer (that I would have never imagined to pop up) with a genuine, serious problem.

What we found

The Telemetry Buddy came back pointing to a customer with massive performance issues. I mean… whoopsy .

Some stats:

• 32.3 hours of wasted processing time in a single morning
• 58% of it (18.8 hours) coming from a single CodeUnit: ISC Process Update Queue Meth (ID 2037111)
• 19,946 slow SQL queries averaging 3.4 seconds each (should be under 750ms)
• A midnight spike that showed 24.3 hours wasted in the first hour alone
• Job Queue Dispatcher taking 70+ minutes per job (normally should be under 5 minutes)

This wasn’t just “things are a bit slow.” This was a background job continuously polling a queue, hitting a HUUUGE table, and basically .. well .. a catastrophe waiting to happen.

The investigation

Once I realized this wasn’t just a fun demo anymore, I dove deeper (and yeah, I kept showing my kid what I was doing .. he thought it was cool that we’d found a “real issue” ).

The pattern was clear:

A background queue processor codeunit was running a simple query.  Something in the likes of:

SELECT TOP (1) “Entry No_”, “Item No_”, “Process Type”…
FROM “ISC ItemSearch Update Queue”

This should be lightning-fast. Milliseconds!  I mean .. a FindFirst in AL – come on .

Instead? 3+ seconds per query. Sometimes up to 5.4 seconds.

Why? 

Well – knowing the queue table, I knew it had to be pretty much empty: we pretty much empty it daily with retention policy.

On top of that .. the queue table had no proper indexes on the fields being queried. Every single TOP 1 query was doing a full table scan. And this job was running continuously …

The fix

I had the Telemetry Buddy document everything (that’s pretty much the reason why you’re getting quite exact stats in this blogpost ;-)) – and went with my hunch: did we forget to set up the retention policy?

And indeed: we did not.  Simple fix, isn’t it?

On top of that, we also added the index in the product, because that was clearly the decent thing to do!

FYI – both solutions were suggested by the AI :-).

The validation

The nice thing when you “save” your investigations (I simply use the BCTelemetryBuddy agents that are part of the VSCode Extension and ask the AI: “Save the conclusions we made in this chat”, which drafts an md-file in your workspace) – is that you can follow up on it!

So .. fast forward to about a month later, when I ran the same telemetry analysis to confirm the fix:

Before:

• 19,946 queries per morning
• 3.4 seconds average
• 67.7 hours of wasted time

After:

• 18 queries total in 7 days
• 0.8 seconds average
• Virtually zero waste

Clean. Healthy. Fixed.

Job Queue Dispatcher? Down from 70+ minutes to under 25 minutes max.

Why this matters

This whole experience perfectly demonstrates what I’ve been building with the BC Telemetry Buddy:

Without the buddy, finding this would have required:

1. Customer complains (maybe – remember, users weren’t directly affected)
2. Manually analyze with the dataexplorer, or may be with a bunch of manually written KQL
   1. Dig into SQL statements
   2. Dig into stacktraces
   3. Durations
   4. Analyze patterns in time, per object, per sql statement, …
   5. Quantify impact
3. …

And all that with quite deep investment in KQL and BC Telemetry knowledge!

You guess how much time that would have cost..

With BC Telemetry Buddy .. I literally asked: “What customer has the most reason to complain?”

One question. One answer. Immediate diagnosis with lots of details!

Time investment: 15 minutes from question to detailed diagnosis .. another 15 to fix it.

Conclusion

So yeah… I asked a question that was meant as a joke .. to demonstrate a tool to my 12-year-old, and we ended up finding a critical performance issue.

The BC Telemetry Buddy worked exactly as intended .. and boy – was I proud and happy.  It was what convinced me: this thing has potential!

Got questions? Issues? Ideas? Hit up the GitHub issues. I’m always looking for feedback and real-world use cases

Happy Holidays!

Original Post https://waldo.be/2025/12/24/bc-telemetry-buddy-when-your-12-year-old-accidentally-helps-you-find-a-problem/