Configuring Diagnostic Settings

1. Start Locally

Firstly, we need to launch Locally which we can do from a terminal by running:

Once Locally has started, the Locally Dashboard will open automatically:

2. Create a Resource Group

Next we can create the Resource Group:

There's two things to note here:

1. The Azure CLI supports Automatic Configuration, meaning that it can automatically be configured to work against Locally just by prefixing commands with locally run.
2. Locally intentionally uses a different set of locations to Azure as a safety precaution, so that you can be confident you're deploying against Locally rather than regular Azure. You can also configure Locally to use the Azure locations too, but you'll want to be extra sure that you're prefixing commands with locally run when you do.

3. Create the Workspace

The logs need somewhere to go, so let's create a Log Analytics Workspace:

{
  "customerId": "e529fa93-3736-44bf-9369-0413f2c2982e",
  "name": "sample-diag-workspace",
  "retentionInDays": 30,
  "sku": "PerGB2018"
}

The Diagnostic Setting refers to the workspace by its resource ID, so let's keep hold of that:

4. Create a Web App

Now we need a resource that produces logs. A Web App needs an App Service Plan to run on:

Then we can create the Web App itself, running a small container that echoes back each request it receives:

{
  "host": "samplediagapp1.furnace.locally:5663",
  "name": "samplediagapp1",
  "state": "Running"
}

And keep hold of its resource ID too, since that's what the Diagnostic Setting attaches to:

5. Create the Diagnostic Setting

Let's send the Web App's HTTP and console logs to the workspace:

{
  "logs": [
    {
      "category": "AppServiceHTTPLogs",
      "enabled": true
    },
    {
      "category": "AppServiceConsoleLogs",
      "enabled": true
    }
  ],
  "name": "send-to-logs",
  "workspaceId": "/subscriptions/307d8f52-9719-460e-9f85-aa408e28ee55/resourceGroups/sample-diagnostics/providers/Microsoft.OperationalInsights/workspaces/sample-diag-workspace"
}

We can list the Diagnostic Settings on the Web App, along with the categories each one sends:

Name          Categories
------------  -----------------------------------------
send-to-logs  AppServiceHTTPLogs, AppServiceConsoleLogs

6. Send the Web App a request

Now we need something to log. Let's send the Web App a request:

200

If you get a 502, the container is still starting - give it a few seconds and try again.

7. Query the Workspace

Queries identify the workspace by its workspace ID (customerId) rather than its resource ID:

Then we can look for the request in the AppServiceHTTPLogs table:

Time                  Method    Path    Status
--------------------  --------  ------  --------
2026-10-05T15:54:06Z  GET       /hello  200

Logs usually arrive within a few seconds, so if the table is empty, wait a moment and run the query again.

We can see the Web App in the Locally Dashboard too:

8. Tidy up

Finally, we can tidy up. To remove just the Diagnostic Setting:

Or to remove the Resource Group and everything within it:

Doing this with other tooling

Whilst this guide used the Azure CLI, Diagnostic Settings work the same way through any of the tooling that Locally supports - a Microsoft.Insights/diagnosticSettings resource in HashiCorp Terraform or OpenTofu, Pulumi, Bicep or an ARM Template all provision against Locally in the same way, with only the location changed.

Next steps

Only the Activity Log, Web Apps and Function Apps send logs this way so far - the Log Analytics Emulator has the details. To be told when something happens rather than query for it, see Alerts.

Should you encounter any issues, please take a look at the troubleshooting section.