Do you hear about outages from your users? Monitoring a .NET application with Application Insights

Monday, 9:15. A customer calls: “It’s not working.” The team logs into the server and digs through logs, and an hour later someone realises the database connection broke at three in the morning. The application was half dead for six hours, and you heard about it from a customer.

The question isn’t whether this will happen. It’s whether you will be the first to know.

What you see once monitoring is set up

Application Insights is Microsoft’s application monitoring tool on Azure. With it switched on, the difference looks like this:

Question	Without monitoring	With Application Insights
Is the application up right now?	Someone opens it and looks	An availability test every few minutes, and an alert if it fails
Why is it slow?	Guesswork	The exact screen, the database query and how long it takes
What broke at three in the morning?	Digging through logs on the server	The error with its full trace, in one place
How many users were affected?	Nobody knows	The number of failed requests and affected users
Is an external service to blame?	Finger-pointing	Every call to the database and external APIs, with duration and result

For a manager that means two things: you hear about a problem before the customer does, and when you sit down to discuss what happened, there are numbers on the table, not impressions.

Setting it up: a few lines of code

For an ASP.NET Core application, it’s enough to add Microsoft’s Azure.Monitor.OpenTelemetry.AspNetCore package and one line in Program.cs:

builder.Services.AddOpenTelemetry().UseAzureMonitor();   // requests, errors, database and external calls

var app = builder.Build();

app.MapHealthChecks("/health");                          // the address the availability test checks

The connection to Application Insights goes through the APPLICATIONINSIGHTS_CONNECTION_STRING setting in App Service, not through code. From then on, every request, error and call to the database and external services is recorded automatically.

That’s the easy part. The hard part is deciding what should wake you up at three in the morning and what can wait until the morning.

Five alerts every application needs

1. The availability test failed. Every few minutes, Azure opens your application from several locations around the world. If it doesn’t respond, you get an alert.
2. A sudden rise in failed requests. When errors jump above their usual level, something has changed, usually a new version or an external service.
3. Responses get slow. Response time above an agreed threshold for more than a few minutes.
4. Calls to the database or external services fail. The most common cause of “the app doesn’t work” that isn’t in your own code.
5. The server is at its limit. CPU or memory above, say, 80% for a long time. A warning before it turns into an outage.

An alert has to reach a person who will act on it, by email, text message or in Teams. An alert that lands in an inbox nobody reads is the same as no alert at all.

If you use the old availability tests: the deadline is 30 September 2026

Microsoft retires the old URL ping tests in Application Insights on 30 September 2026. If you still use them, move them to standard tests. Otherwise your availability monitoring will quietly stop working, which is exactly the kind of failure you’d want an alert for.

Keeping monitoring from eating the bill

Application Insights is billed by the amount of data it records. That’s why some companies end up paying more for monitoring than for the application itself. Three things keep it under control:

• Sampling. You don’t need to record every successful request. A representative share is enough, and errors are all kept.
• Log level. Production doesn’t need everything that gets written out during development. Detailed logs are switched on while investigating something, then switched off again.
• A daily cap. An upper limit as a safety net, in case some error suddenly starts writing thousands of entries a minute.

How we roll it out

1. Switch onPackage, setting, availability test
2. AlertsFive alerts, to the right people
3. OverviewOne screen for application health
4. RoutineA weekly look at the trends

Once monitoring works, the next step is to use it: which screens are slowest and which errors keep coming back. It’s the same measuring we wrote about in the article on slow applications, except that now the data arrives on its own.

How we work

ProCoding is a .NET studio from Split, Croatia, and Azure for .NET applications is one of our specialisations. We set up monitoring, alerts and a cost review as part of an Azure health check, or together with your team. The first step is a free 30-minute call.

Sources

• Application Insights availability tests, Microsoft Learn
• Enable Azure Monitor OpenTelemetry for .NET applications, Microsoft Learn