Read Business Central telemetry without KQL

Business Central emits a large amount of telemetry, and almost nobody reads it. The reason is not indifference. The reason is that the data arrives as KQL queries over an Application Insights workspace, and most of the people who need the answers do not write KQL.

You do not have to. This page gives the event IDs that carry the story, what each one means, and the questions you can answer once you know them.

Where does Business Central telemetry go?

To the Application Insights resource that you connect to the environment. Business Central writes signals there as traces, each one carrying an event ID and a set of custom dimensions.

The event ID is the whole navigation system. Microsoft publishes the full list, and once you know six of them you can answer most operational questions.

Which event IDs carry the story?

These are the identifiers and the descriptions from Microsoft's own table.

Two of these are more useful than their names suggest.

RT0004 is how you count usage. There is no "session" event. You count successful authorizations to open a company, grouped by user and by day. That gives daily, weekly and monthly active users.

RT0030 is how you find the pain. It records the error dialogs that users actually saw. Not the exceptions in a log, the dialogs in front of a person. Ranking RT0030 by message and by count produces the shortest list of real problems any Business Central environment can give you.

The five questions worth asking

Who uses this environment, and is that changing? RT0004, grouped by user and day. Compare the current period against the period before it. A drop after an update is the signal you want to see quickly.

What is slow, and is it SQL or AL? RT0005 and RT0018 together. The split matters. A slow SQL query is usually a missing index, or a filter that cannot seek. A slow AL method is usually a loop that should have been a query.

What is failing in front of people? RT0030, ranked by message. Then take the top three to whoever owns the process.

Who is calling us, and how hard? RT0008 for incoming and RT0019 for outgoing, grouped by endpoint. An integration that quietly tripled its call rate shows up here before it shows up in a complaint.

Did the last extension update work? The LC00xx pairs. LC0021 and LC0023 are the ones to alert on, because a failed compile or a failed update is a fault you want to hear about from telemetry, not from a user.

The KQL limits that surprise people

Two of these cost an afternoon each.

Log Analytics has no percentileif. You will want it immediately, because the natural question is "the 95th percentile duration for this one operation". Mask the rows first with iff, then apply percentile to the masked column.

Custom dimensions are strings. Durations, row counts and every other number arrive as text. Cast before you compare, or a filter on a duration will compare strings and silently return the wrong rows.

Add one habit to both: always look at the time range. Application Insights defaults can quietly limit what you query, and a query that returns nothing is more often a range problem than a data problem.

How to read it without writing KQL

Three routes, in increasing order of effort.

Use the Business Central telemetry Power BI app. It covers the common questions and needs no query writing.

Ask an assistant that runs the KQL for you. A tool that reads your Application Insights workspace can answer in plain language, provided it does two things: it shows you the KQL it ran, and it explains each event ID rather than handing you a raw properties bag. An event ID with no explanation is not an answer, it is a lookup task.

Learn six queries. If you write KQL twice a year, learn the five questions above as five saved queries and stop there. The marginal value of the seventh query is low.

What telemetry will not tell you

It will not tell you why. RT0005 tells you a query exceeded the threshold. It does not tell you that a user built a filter on a non-indexed field because the page does not offer the right one.

It will not tell you about the work that did not happen. An extension that makes a process so slow people stop using it shows as less telemetry, not as more.

And it will not name the business impact. A failed posting is one row here and a month-end problem there. Telemetry points at the operation. A person still has to connect it to the process.

That is the right division of labour. Telemetry narrows a question from the whole environment to one operation, one extension and one hour. The rest is consultancy, and it is much cheaper once the search is finished.