Most estates do not lack alerts. They have too many, and the team has quietly learned which ones to ignore. Once that happens, the alert that matters arrives in the same inbox as forty that do not, and gets the same treatment.
What an alert is for
An alert interrupts a person. That is only worth doing if there is something that person should do now. In our practice an alert earns its place when it passes three tests:
- Actionable: the person receiving it knows what to check first, and there is something they can do about it.
- Owned: it goes to a named person or rotation, not to a shared mailbox that everyone assumes someone else reads.
- Rare: it fires seldom enough that its arrival means something. An alert that fires every day is a report, and belongs in one.
Everything that fails those tests still has value, as a trend on a dashboard or a line in a weekly review. It just should not wake anyone up.
Where the signals come from
For Business Central, the platform's telemetry in Application Insights is the starting point. Microsoft documents several ways to alert on it: metrics in the Power BI telemetry app for a no-code approach, or Application Insights alerts, Azure Logic Apps and Power Automate, each driven by a KQL query that defines the condition. That means an alert can be about something the business cares about, such as a job queue entry failing, or posting taking longer than its baseline, rather than only about CPU.
For the Azure resources around it, Azure Monitor alert rules evaluate a condition and, when it is met, trigger an action group that notifies people or starts an automated response. Microsoft's best practices start with the basics many estates skip: alert rules for service health and resource health, so a platform incident is known before users report it.
Observe, analyze, act, deliver
The film's four steps are a useful test for any alert. Observe: did it fire on something real? Analyze: did the person know where to look? Act: did they do something? Deliver: did the business outcome improve, the posting finish, the integration catch up? An alert that never gets past the first step is noise, however well it is configured.
In our experience, alerts written about business outcomes age better than alerts written about infrastructure. A CPU threshold has to be retuned every time the hardware or the workload changes; "invoices from the integration have not arrived for an hour" stays true and stays actionable through every upgrade, because it describes the thing the business actually needs.
An alert someone can act on
The difference between an alert that gets acted on and one that gets acknowledged is usually the text, not the threshold. In our practice a good alert answers five questions before anyone opens a console:
- What happened, in the business's words: "Job queue entry for nightly posting failed", not "Error count > 0".
- Why it matters: what stops, or who notices, if nobody acts.
- Where to look first: the query, page or log that shows the detail.
- Who owns it: a named person or rotation.
- When to escalate: what makes this an incident rather than a task.
Writing those five lines for each alert is also the quickest review there is. An alert for which nobody can write the second line is a candidate for deletion.
The traps
- Alerting on every metric because it is available. Availability of a signal is not a reason to interrupt someone with it.
- Thresholds set once and never revisited. A threshold that made sense before the last major change may now fire every day.
- Alerts without a first step. If the person receiving it has to start from nothing, the alert has only moved the problem.
Five checks for this week
- Export a month of alerts and sort them into two piles: the ones where somebody did something, and the ones somebody only acknowledged.
- For the second pile, decide for each alert: tune it, turn it into a report, or delete it.
- Make sure service health and resource health alerts exist for the Azure resources your estate depends on.
- Pick one business outcome, such as failed job queue entries, and alert on it from Business Central telemetry.
- Give every remaining alert a named owner and a one-line first step.
Veltheon is founder-led, based in Ontario, and works on Business Central and NAV, SQL Server and Azure. If one of these sounded like your estate, the first conversation is free and starts with the evidence you already have.
Sources and credits
- Alert on telemetry — Microsoft Learn: Power BI metrics, Application Insights alerts, Logic Apps and Power Automate
- Monitoring and analyzing telemetry — Microsoft Learn: Business Central telemetry
- Azure Monitor alerts overview — Microsoft Learn: alert rules and action groups
- Best practices for Azure Monitor alerts — Microsoft Learn: service health and resource health alert rules
- Creative Commons Attribution 4.0 (CC BY 4.0) — the documentation licence
Original Veltheon explanation. The films are illustrative artwork, not Microsoft or customer footage, and nothing here is a measured result from a customer system. Verify current documentation and your actual environment before changing anything.
Documentation references: Microsoft and contributors, Microsoft Learn (Business Central, SQL Server and Azure documentation), licensed CC BY 4.0. Concepts summarized by Veltheon; source wording and layout not reproduced.
Veltheon Field Notes is an independent publication, neither affiliated with nor authorized, sponsored or approved by Microsoft Corporation. Microsoft, Dynamics 365, Business Central, Dynamics NAV, SQL Server and Azure are trademarks of the Microsoft group of companies.
These are the personal views of Neeraj Kumar, based on about two decades of enterprise experience. General information, not advice for your environment.