Business Central telemetry: what to monitor in a retail estate
On-premises, a slow Business Central system could be investigated on the server and in SQL directly. Online, that access is gone by design — multi-tenancy removes it. Telemetry sent to Azure Application Insights is the replacement lens: the environment emits signals about what it is doing, and the admin reads them there instead. The problem is volume. Microsoft documents dozens of telemetry areas, and a small retail team cannot watch all of them. This guide ranks the documented signals by what actually breaks a store day, then turns the ranking into a short review routine.
First, telemetry has to be switched on
Nothing below exists until each environment is connected to an Application Insights resource. For Business Central online, the documented admin center procedure is:
- Create the Application Insights resource in Azure first, and copy its connection string from the resource's Overview page.
- Open the admin center, select Environments, and select the environment to connect.
- Check the Application Insights Key field on the Environment page — it shows whether the environment already sends telemetry.
- Choose Define, and in the Set Application Insights Key pane, turn on Enable application insights and enter the key or connection string.
- Save — outside trading hours. Saving triggers an automatic restart of the environment, so plan the change for a quiet period, not a Saturday morning.
One Application Insights resource can serve multiple tenants and environments, so a single resource can cover production and sandbox side by side. If data does not arrive after setup, Microsoft's documented checks are the connection string itself and whether telemetry was enabled in the correct environment. To stop telemetry later, set the connection string or key back to a blank value.
The signals that matter for stores, in priority order
Microsoft's available-telemetry reference describes each area in one line. Read against a retail estate — POS-adjacent integrations, background posting, scheduled reports — the areas sort like this:
| Telemetry area | What Microsoft documents it records | Why it ranks here for retail |
|---|---|---|
| Job queue | Creating and running job queue entries | Scheduled reports and background jobs are store infrastructure; a silent failure here surfaces as missing numbers at close |
| Report generation | Execution of reports | Daily sales and inventory reports are how head office sees the stores |
| Long running operation (SQL query) | SQL queries that take longer than expected to execute | The first place to look when pages or reports crawl |
| Long running AL method trace | Long running AL methods | Separates slow code — often extension code — from slow database work |
| Web service requests (incoming and outgoing) | Execution time of web service requests in both directions | Integrations ride on web services; aggressive calling patterns degrade the whole environment |
| Database deadlocks, lock timeouts, wait statistics | Deadlocks that occur, locks that timed out, and the wait categories and times a query runs into | Explains the "everything froze for ten minutes" report from a store |
| Authorization | User sign-in attempts, with success or failure and the reason for failure | Sign-in problems and slow session starts land here first |
| Extension lifecycle | Success or failure of extension operations such as publishing, synchronizing, and installing | The prime suspect when a page suddenly slows after a change |
| Company lifecycle | Creating, copying, and deleting companies | A company copy running during trading hours explains estate-wide slowness |
| Task scheduler lifecycle | Execution of scheduled tasks | The layer under the job queue; useful when entries look right but nothing runs |
Everything else in the reference — feature usage, field monitoring, financial report usage, and the rest — is legitimate telemetry, but it answers adoption and audit questions, not "why is the store struggling today" questions. It can wait.
Reading a slowdown: which signal answers which complaint
Microsoft's performance-troubleshooting guidance maps symptoms to signals. Applied to the complaints a retail admin actually hears:
| Complaint | First signal to check | Documented reason |
|---|---|---|
| Sign-in is slow, or pages using background tasks crawl | Authorization | Each page background task opens a new session, and an expensive OnCompanyOpen trigger slows down opening new sessions |
| Everything was slow for a period, then fine | Company lifecycle, then database locks | A copy-company operation may have been running at the time, or the cause may have been database locking |
| A specific page suddenly got slow | Extension lifecycle | An extension may have been installed that interferes with the page |
| Pages or reports take too long to load | Long running SQL queries | The data operations behind the page or report may be taking a long time to complete |
| One report is slow | Report signal | The report may be reading more data than expected |
| The whole interface feels sluggish | Web service requests | Calling the environment too aggressively with web service requests can affect performance of the system |
The pattern matters more than any single row: start from the complaint, not from a dashboard. Telemetry rewards a specific question.
A sane review routine
Daily — five minutes, before stores open. Check the job queue signals for errored entries. The documented job queue lifecycle events make this a precise query rather than a scroll: AL0000E24 (entry enqueued), AL0000E25 (started), AL0000E26 (finished), and AL0000HE7 (errored). A HE7 with no matching E26 afterwards is a job that died in the night. Then check report failures: report telemetry records whether each report succeeded, failed, or was canceled, how long it ran, how many SQL statements it executed, and how many rows it consumed — and a failed report generation emits an RT0006 event whose result dimension carries the exception title. A scheduled sales report that failed at 2 a.m. is visible here before the store manager phones about it. (The job queue side of that report is covered in our guide to scheduling reports.)
Weekly — fifteen minutes. Review the long-running SQL and long-running AL signals for repeat offenders: the same query or method appearing every day is a fix-or-escalate item, not background noise. Skim web service request execution times for integrations trending upward. Check the authorization signal for sign-in failure patterns — a rising failure count with a documented reason is an early warning, not a helpdesk surprise.
After any change. Extension installs, environment updates, and company copies all have lifecycle signals. When a store reports slowness the morning after a change, correlate the time window against extension lifecycle and company lifecycle events before touching anything else.
One setup detail makes all of this sharper: assign each user a telemetry ID. The Telemetry ID field on the User Card holds a GUID used only for telemetry, and it appears in the user_Id column in certain events — which turns "a cashier had a problem at 11:00" into a filterable query.
What success looks like: the daily check ends with every overnight job queue entry showing a finished event, zero unexplained RT0006 failures, and any errored entry already restarted or escalated — before the first store opens.
What telemetry will not tell you
Telemetry is logged into the traces and pageViews tables in Application Insights — it is not a page inside Business Central, and it only covers the documented areas. If an operation has no signal in the reference, there is no telemetry for it, and no query will invent it. It also explains the Business Central side of a problem: when the signal set is clean but a store still struggles, the cause sits outside the environment — local network, local hardware, or the integration's other end — and telemetry has done its job by proving that.
FAQ
Where does Business Central telemetry actually land?
In the connected Azure Application Insights resource, in the traces and pageViews
tables. Analysis happens there, typically with KQL queries, not inside Business
Central.
Can one Application Insights resource cover several environments?
Yes — Microsoft documents that the same resource can be used for multiple tenants and
their different environments, so production and sandbox can share one resource and be
separated by query.
A scheduled report failed overnight. Where is that visible?
In two places: the job queue lifecycle events (an errored event, AL0000HE7, for the
entry that ran it) and report telemetry, where the failed generation appears as an
RT0006 event with the exception title in the result dimension.