How can developers identify database performance bottlenecks using Business Central telemetry?

Business Central telemetry is valuable because it changes performance troubleshooting from “users say the system is slow” to an evidence-based investigation of where time is actually being spent. Business Central can send telemetry to Azure Application Insights, where developers and administrators can analyze performance signals across environments, users, applications, and extensions.

A practical investigation can start by identifying the symptom, timeframe, affected operation, and frequency. From there, telemetry can help correlate slow pages or reports with long-running SQL queries, database locks, wait statistics, web-service activity, reports, extensions, or other operations occurring at the same time. This correlation is important because the slow component is not always the component that originally triggered the user complaint.

For database-level investigation, long-running SQL query telemetry is particularly useful. Business Central records SQL queries exceeding its long-running threshold; Microsoft currently documents a 750 ms threshold for these telemetry events. The telemetry can include execution time, SQL statement information, SQL session information, the AL object involved, and an AL stack trace, giving developers clues about which application code generated the expensive database operation.

However, a slow query does not automatically mean the query itself is poorly written. The database may be waiting for a lock, the operation may be affected by missing indexes, or another workload may be consuming resources. Business Central also exposes database wait statistics, which provide information about wait categories and wait times, helping developers investigate what the database was waiting for rather than looking only at query duration.

This leads to a useful troubleshooting sequence:

User reports slowness
→ Identify the affected scenario
→ Check telemetry during the relevant period
→ Identify long-running operations
→ Examine SQL/query and AL context
→ Check database locks and wait statistics
→ Investigate missing indexes or inefficient data access
→ Review the responsible AL code or extension
→ Make a targeted change
→ Measure the result again

For developers, KQL is an important practical skill because Business Central telemetry stored in Application Insights can be queried using Kusto Query Language. KQL allows teams to filter events by time, environment, company, application, operation, and other dimensions and identify recurring performance patterns rather than investigating isolated incidents.

Another important point is frequency versus duration. A query taking two seconds once may be less significant than a query taking 300 milliseconds that executes thousands of times. Business Central's additional logging can capture all SQL queries for a specific session for short-term investigation, which can help identify frequently executed queries that do not necessarily cross the normal long-running threshold.

Telemetry can also help identify problems outside SQL. For example, Microsoft documents signals for database locks, long-running AL operations, reports, web-service requests, sessions, and other activities. This gives developers a broader view of the application instead of assuming every performance problem is a database-index problem.

For students and freshers, the key lesson is to learn how to investigate performance rather than immediately change code. Before adding an index, rewriting a FindSet, changing filters, or modifying a report, first establish evidence for the bottleneck.

For experienced Business Central developers, the deeper skill is connecting:

Telemetry → KQL → SQL behavior → AL call stack → Extension → Data access pattern → Business scenario

That connection helps turn telemetry into an actual optimization process.

A good real-world exercise would be to take a slow Business Central report or page, identify its long-running operations through telemetry, investigate the associated AL code, examine database waits and missing-index information where applicable, make one controlled optimization, and then compare the telemetry before and after the change.

The goal is not simply to make a query faster. The goal is to be able to answer: