Monitor Azure Functions with Application Insights (2026)

Azure Functions are designed to be event-driven, but the real magic happens when you can see those events and the code they trigger. Application Insights is your window into that world, turning a distributed, ephemeral system into something you can actually debug and optimize.

Let’s look at a simple HTTP-triggered Azure Function and how it appears in Application Insights.

function.json

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    }
  ]
}

index.js

module.exports = async function (context, req) {
    context.log('JavaScript HTTP trigger function processed a request.');

    const name = (req.query.name || (req.body && req.body.name));
    const responseMessage = name
        ? "Hello, " + name + ". This HTTP triggered function executed successfully."
        : "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response.";

    context.res = {
        // status: 200, /* Defaults to 200 */
        body: responseMessage
    };
};

When this function is deployed to Azure and receives a request (e.g., GET /api/MyHttpFunction?name=World), Application Insights captures several key pieces of information.

First, we see an HTTP Request trace. This shows the URL, the HTTP method, the response status code, and the duration of the request. Crucially, it also includes a operation_Id. This operation_Id is the thread that ties everything together.

Next, we see Trace messages. These correspond to context.log() calls within our function. You can see our initial log message: "JavaScript HTTP trigger function processed a request."

If our function called another Azure service (like Cosmos DB or Service Bus), we would see Dependency traces. These show the outgoing call, the target service, the duration, and whether it succeeded or failed. This is vital for understanding performance bottlenecks and inter-service communication issues.

The real power comes from the operation_Id. If you search for this ID in Application Insights, you can see the entire lifecycle of that specific request: the initial HTTP request, all the logs generated, any dependencies called, and any exceptions that occurred. This provides a correlated view across all the telemetry generated by that single invocation.

To get this working, you need to configure your Azure Function App to send telemetry to an Application Insights resource. This is typically done via an Application Settings key named APPLICATIONINSIGHTS_CONNECTION_STRING.

az functionapp config appsettings set --name <your-function-app-name> --resource-group <your-resource-group> --settings APPLICATIONINSIGHTS_CONNECTION_STRING="<your-connection-string>"

The most surprising thing about Application Insights for Azure Functions is how it automatically correlates telemetry across distributed calls without explicit code instrumentation. The operation_Id and parent_operation_Id are automatically propagated by the Azure Functions host when it knows it’s running within an Application Insights-enabled environment. This means even if your function calls another function or an external service that also sends telemetry, you can trace the entire flow.

The next concept you’ll want to master is using custom events and metrics to gain deeper insights into your function’s business logic, rather than just its execution.