Home
Dynamics 365
Business Central
Troubleshooting Series – Ep5 – Telemetry

Troubleshooting Series – Ep5 – Telemetry

WaldoBusiness Central2 hours ago20 Views

Next topic in the troubleshooting series: Telemetry. Probably the biggest one yet – and one that’s quite close to my heart, as I’ve been spending a ridiculous amount of time on it over the past years. As always in this series – I just want to throw a bit of “waldo”-sauce on there, with my own take on the topic .

But before we start, here’s an overview of the series so far:

Why you should care

Let’s be real: troubleshooting Business Central SaaS without telemetry is like debugging with your eyes closed. You don’t have SQL access, you can’t install profilers on the customer’s machine, and reproducing issues is .. well .. good luck .

Telemetry gives you evidence. When did it start? How often does it happen? Which customer, which environment, which extension, which object? When you can answer those questions with actual data .. you massively shorten the time-to-fix. And that’s not just good for you – it’s good for the customer calling you at 8 am on a Monday telling you “it’s slow” (obviously, without any more information) .

A few things that telemetry unlocks that you simply can’t do otherwise:

You got a crapload of performance metrics: Instead of guessing, you can look at long-running SQL queries, long-running AL methods, lock timeouts, deadlocks .. and focus on what actually hurts.
You can even become more pro-active: You can set up alerts on error spikes, sudden jumps in long-running operations, or “customer got a new extension installed and now everything broke”. It’s not hard to set up – and it changes how you work.
Evidence beats opinions. I can’t stress this enough. “It feels slow” turns into “this report runs 14 seconds on average since Tuesday” .. which is a very different conversation to have.

In any case – let’s not repeat Microsoft’s documentation – which is actually pretty good: Monitoring and Analyzing Telemetry.

The two “channels” of telemetry

Although .. I DO want to address this last piece separately .. . Namely, there are two levels of telemetry:

Environment-level telemetry – configured per environment in the Admin Center. This gives you the “platform view”: logins, errors, performance, lifecycle events, .. basically everything the BC service emits.
App/Extension-level telemetry – configured in your app.json with an Application Insights connection string. This gives you everything your extension does – and it’s the way to go for ISVs or partner apps that want their own telemetry pipeline.

(More details: Enable Telemetry)

What I wanted to address separately, is the ISV Telemetry – because the amount of data the ISV gets .. is simply not enough to really nail down issues at this moment – to really put the finger on the wound. ISV’s don’t have the context of the process, the operation, ALL surrounding telemetry for the customer, so for ISV’s it’s sometimes difficult to attach a certain problem to the actual cause.

So – if you are a VAR that are using ISV apps that have problems – help the ISV and report the full scope of the problem to your ISV so they get more data, and can make conscious decisions in how to improve their product!

My telemetry journey (the short version)

I’ve been doing telemetry sessions for a while now .. and every time I think “this is it” – something new comes along that changes everything. Let me give you a timeline.

Azure Data Explorer (2024)

In 2024, I did a session at BCTechDays where I introduced Azure Data Explorer as the tool for developers to explore BC telemetry. And I stand by that – for interactive, ad-hoc querying across large datasets and multiple customers, ADE is ridiculously powerful. I also blogged about my ADE dashboard and the follow-up.

“Hey Copilot, How’s My Business Central Doing” (2025)

A year later, Dmitry Katson and I did a session where we introduced the concept of asking questions to an LLM – which would look up KQL queries stored in a vector database and come up with an answer. Cool concept at the time.

But then .. agents and MCPs happened

Yeah. That concept was old before we realized it. “Agents” and “MCPs” came into the picture – and suddenly we were able to do things much more elegantly. Which is where the BC Telemetry Buddy comes in – you must have heard about it .. .

What Microsoft gives you (don’t skip this!)

Before you go building anything custom – there’s a lot of ready-made stuff that Microsoft provides. Don’t reinvent the wheel.

Telemetry Event IDs

Microsoft maintains a structured list of all Telemetry Event IDs – this is THE reference when you want to know which signals exist and how to filter on them.

Power BI telemetry apps

Microsoft provides two Power BI apps (environments and apps/extensions) – free through AppSource (Power BI Pro required). If you don’t want to write KQL – this is your starting point. Usage, Errors, Performance, Administration .., all nicely visualized.

The BCTech repository

The BCTech repository on GitHub is a goldmine: sample KQL queries organized by signal type, sample dashboards for Azure Data Explorer, Power BI templates, guides .. basically everything you’d need to get started.

“Enable additional logging” – your 15-minute SQL profiler

This is one I want to highlight because it’s easy to forget while you might really need it.

In the Help & Support page, users can temporarily enable Additional logging. What this does: for about 15 minutes, BC emits much more verbose telemetry – including all SQL queries, not just the long-running ones.

When should you use it?

Well – do you want a SaaS SQL Profiler? For 15 minutes? Here you go .

More info: Enable Additional Logging.

And then there’s the BC Telemetry Buddy

So – with all of the above – you might think “that’s a lot of tools and approaches”. And you’d be right. That’s exactly why I built the BC Telemetry Buddy – an MCP (with optional VS Code extension) that makes it easy to query and analyze BC telemetry without needing to know KQL, without needing to leave your IDE, and optionally with AI assistance through GitHub Copilot, Claude, or whatever (bold claim, I only tested these two ;-)) LLM you use.

Think about it: LLM is really bad in interpreting big data (like Telemetry), but it’s really good in writing queries (like KQL) – so the MCP makes LLMs capable of interpreting “big data” by generating decent, easy-to-understand datasets by KQL.

BAM!

I already blogged about it in the past few posts:

The short pitch: you install the extension, point it at your Application Insights, and just ask questions in Copilot Chat:

“Show me all errors in the last 24 hours”
“What customer has the most long-running queries?”
“Which reports are causing timeouts?”
…

Behind the scenes, it discovers which events exist, understands the schema, checks your saved queries, and generates the right KQL. No need to become a KQL expert. And no – you don’t need a fancy AI subscription – it just uses your existing GitHub Copilot or Claude or … .

Is it the end of the line? Probably not – knowing how fast things move in this space . But right now, it’s the most comfortable way I’ve found to work with BC telemetry . And .. I already have 30 features I’d like to work on to extend the tool .. more IS coming!

Conclusion

Telemetry is not optional anymore. It’s THE way to troubleshoot Business Central SaaS – and honestly, even for OnPrem it’s evenly important. The tooling around it has evolved massively: from raw KQL in the Azure portal, to ADE dashboards, to Power BI apps, to AI-assisted querying. And it’ll keep evolving.

But we are at a stage where Telemetry is available to everyone in the organization – just be brave and start dive into it!

Nee resources? Here are some I found …