Key takeaways
- Monitor from outside Azure as well as inside, or you miss what customers experience.
- Alert on latency percentiles and error rate, not on average response time.
- Watch platform limits alongside app metrics, since quotas throttle before the code fails.
To monitor the performance of an API deployed on Azure, use three layers: Application Insights inside the app for request rate, duration and failures, Azure Monitor for platform metrics and alerts, and an availability test that calls the API from outside. Azure API Management adds per-API analytics if you publish through it. Pair that with a load test before launch, so you know what “normal” looks like. Microsoft’s documentation changed in several places since 2024, and this guide follows the current pages (checked October 2026).
What does Azure give you to monitor an API?
Azure Monitor is the umbrella: it collects metrics and logs from Azure resources, stores logs in a Log Analytics workspace, and runs alert rules. Application Insights is the application performance monitoring feature of Azure Monitor. It collects telemetry from your code (requests, dependencies, exceptions) and gives you the Application map, Live metrics, Failures, Performance and Availability views.
| Tool | What it answers | Where it runs |
|---|---|---|
| Azure Monitor metrics | Is the host healthy? CPU, memory, platform request counts | The platform, no code changes |
| Application Insights | Which operation is slow or failing, and why? | Inside your app, through an SDK or distro |
| Availability tests | Can a client on the internet reach the API right now? | Microsoft test locations, outside your app |
| API Management analytics | Which API, operation, product or subscription is slow or erroring? | The gateway, if you publish through API Management |
| Log Analytics (KQL) | Custom questions across all the above | Query layer over workspace data |
How do I add Application Insights to an API?
Create an Application Insights resource, copy its connection string, and add Microsoft’s OpenTelemetry distro to the app. The 2024 version of this post showed services.AddApplicationInsightsTelemetry(...) with an instrumentation key. That path still works but is now the legacy option: Microsoft says to prefer connection strings because instrumentation keys are legacy, and the Application Insights .NET Classic API SDK 2.x retires on 31 March 2027. For a new ASP.NET Core API, the documented route is:
dotnet add package Microsoft.OpenTelemetry
using Microsoft.OpenTelemetry;
var builder = WebApplication.CreateBuilder(args);
builder.UseMicrosoftOpenTelemetry(options =>
{
options.Exporters = ExportTarget.AzureMonitor;
});
var app = builder.Build();
app.Run();
Set the connection string in the environment, not in code, for production: APPLICATIONINSIGHTS_CONNECTION_STRING="<ConnectionString>". Other languages have equivalents (Node.js, Python and Java). If you already run the Azure Monitor OpenTelemetry Distro, Microsoft says no action is needed. Several services that send to one Application Insights resource need distinct Cloud Role Names, or the Application map merges them.
Two things to know. Microsoft notes that some platforms enable data collection through automatic instrumentation, with no code changes, which is a quick start (AKS auto-instrumentation is a public preview). And ingestion volume affects Application Insights cost, so check what your resource collects before turning everything on.
Which API metrics should I watch?
Watch four signals per operation, not per service.
- Request rate. Requests per second. A sudden jump may be a promotion or a retry storm; a sudden drop may be an upstream failure.
- Error rate. The share of requests that fail. Split 4xx (client mistakes, expired tokens) from 5xx (your problem).
- Duration. Server-side time to answer. Look at percentiles, not the mean. The percentiles article explains why a good average hides the slow tail that real users feel.
- Dependency time. How long calls to databases, caches and other APIs take. A slow API is very often a slow dependency.
Throughput and latency belong in the same picture: how throughput and response time relate shows why latency climbs once a service nears capacity. Alongside these, watch platform limits such as App Service plan CPU and memory, because quotas and CPU saturation throttle an API before the code fails.
How do I set up the monitoring in the Azure portal?
- Open your Application Insights resource and look at Overview, then Investigate > Performance and Failures. Performance lists operations by duration; Failures groups errors by operation and response code.
- Open Live metrics while you send test traffic, to see requests, failures and server response time as they happen.
- Create an alert. In the Azure portal select Monitor > Alerts > Create > Alert rule, pick your resource as the scope, choose a signal on the Condition tab, and decide between a static threshold and a dynamic threshold. Dynamic thresholds learn the metric’s normal pattern and alert on deviations. Attach an action group on the Actions tab to send email, SMS or a webhook.
- Open Logs to query in Kusto Query Language (KQL).
For example, in a workspace-based Application Insights resource this query counts requests per success state over the last hour (the request table is AppRequests in the workspace; the classic requests table name and timestamp column appear in the resource-level Logs view):
AppRequests
| where TimeGenerated > ago(1h)
| summarize count() by Success
To see a duration percentile per operation:
AppRequests
| where TimeGenerated > ago(1h)
| summarize p95 = percentile(DurationMs, 95) by Name
| order by p95 desc
How do I check the API from outside Azure?
Application Insights telemetry only exists for requests that reach your code. A DNS failure, a bad certificate, a firewall rule or a regional network problem produces no telemetry at all, which is why this post’s first takeaway says to monitor from outside as well.
Azure’s own answer is the availability test. In your Application Insights resource open Availability and select Add Standard test. A Standard test sends a single request from the locations you pick, checks the status code, optional content match and certificate validity, and supports different HTTP verbs, custom headers and a request body. Details from Microsoft’s page:
- The classic URL ping test is deprecated. It was first planned to retire on 30 September 2026, and Microsoft has extended that by 24 months to 30 September 2028. Existing ping tests keep running until then, but new work should use Standard tests, and Microsoft documents a PowerShell migration. Standard tests incur charges once enabled.
- Microsoft recommends at least five test locations (up to 16 are available) so you can tell your API’s problems from network problems.
- Retries are available: a failure is reported only if three successive attempts fail, and Microsoft says about 80% of failures disappear on retry.
- Alerts are on by default, and the recommended setup alerts on failures from a minimum number of locations.
- The test must be able to reach the endpoint from the public internet. For private endpoints, Microsoft’s advice is to monitor an internal health signal from inside the network and alert on that.
An API that needs a token on every call can use the custom headers field, but a long-lived token placed in a header is a secret in a test definition. Prefer a dedicated health endpoint that needs no credentials and returns what a client needs (status plus a check of the database), and keep the secured paths under a separate monitor with a rotated, low-privilege token.
How do I use API Management analytics?
If you publish the API through Azure API Management, you get analytics per API, operation, product and subscription, across timeline, geography and request views. Microsoft’s current guide says the recommended way to read them is the Azure Monitor-based dashboard: send gateway logs to a Log Analytics workspace (Monitoring > Diagnostic settings, category “Logs related to ApiManagement Gateway”, destination Log Analytics, resource-specific table) and then open Monitoring > Analytics. A new workspace can take up to two hours to begin receiving data. The older built-in analytics in the classic tiers (shown as Analytics (classic)) will be retired in March 2027. To see detailed per-request data and trace calls through to the backend, integrate API Management with Application Insights too.
How do I load test an Azure API?
Monitoring tells you how the API behaves under the traffic it gets. A load test tells you how it behaves under traffic you choose, before users find out. Azure Load Testing is Microsoft’s managed service for this, now documented under Azure App Testing. It runs Apache JMeter or Locust scripts, or a quick URL-based test, and for Azure-hosted apps it shows server-side metrics (through Azure Monitor and Application Insights) next to the client-side results. It can also stop a run automatically and fail a CI/CD step when criteria such as average response time or error count are breached.
LoadFocus runs JMeter and k6 tests from 25 cloud regions and has a GitHub Action, a Jenkins plugin and a Verdict API for pass/fail results in a pipeline (loadfocus.com/load-testing, October 2026). Whichever tool you choose, run the load test while you watch Application Insights, so the client’s view and the server’s view line up. For more, see strategies for load testing Azure web apps.
What does LoadFocus add to an Azure setup?
LoadFocus API monitoring runs scheduled checks from outside your infrastructure and can be pointed at any public endpoint, including an API hosted on Azure. According to its API monitoring page (October 2026), checks run from 25 cloud regions, can assert on the status code, the response body, headers and response time, support OAuth bearer tokens and chained requests, and alert through email, Slack, Microsoft Teams, PagerDuty, Opsgenie and webhooks, with settings to reduce false alarms (retries, consecutive failures, minimum failing locations). That is an independent second opinion next to Azure’s own availability tests, and it is not tied to one cloud, which matters if the API later moves. Background on the idea is in API monitoring for your business.
A starter alert set
Start small and tune it against real traffic.
| Alert | Signal | Why |
|---|---|---|
| API unreachable | Availability test fails from several locations | Catches what the app cannot see itself |
| Error rate high | Failed requests over a short window | Users are getting errors now |
| Slow tail | p95 or p99 request duration above your target | Real users feel the tail, not the mean |
| Platform pressure | Plan CPU or memory near its limit | Throttling comes before code failures |
Choose the thresholds from your own baseline (a load test and a week of real traffic), not from a number in an article.
Frequently Asked Questions
How do I monitor the performance of an API on Azure?
Add Application Insights to the API for request, dependency and failure telemetry, use Azure Monitor metrics and alert rules for the platform, and add an availability test that calls the API from outside. Read the results in the Performance, Failures and Availability views.
How do I check API traffic in Azure?
In Application Insights open Metrics or Performance to see request counts over time, or run a KQL query against AppRequests. If you publish through API Management, Monitoring > Analytics shows requests by API, operation, product and subscription.
Is the Application Insights URL ping test still available?
Yes, but it is deprecated. Microsoft extended its retirement from 30 September 2026 to 30 September 2028. Create Standard availability tests for new work and migrate existing ping tests before the retirement date.
How do I test Azure API Management performance?
Send realistic traffic through the gateway with a load testing tool (Azure Load Testing, JMeter, k6) and watch the gateway logs and Application Insights while it runs. Postman is useful for checking correctness of single requests, not for load.
How do I check my API response speed?
Application Insights records the duration of each request. Use the Performance view or the DurationMs column in AppRequests, and read p95 and p99 per operation rather than the average.
How do I check whether an API is running?
Use an availability test. A Standard test calls the endpoint from several Microsoft locations at a set frequency and alerts when it fails. A manual curl proves it works from your machine at one moment.
Sources
- Application Insights availability tests (Microsoft Learn)
- Enable OpenTelemetry in Application Insights (Microsoft Learn)
- Application Insights overview (Microsoft Learn)
- Monitor Azure API Management (Microsoft Learn)
- Create Azure Monitor metric alert rules (Microsoft Learn)
- What is Azure Load Testing? (Microsoft Learn)