Azurewebjobsdashboard Connection String

A team I supported deployed a new function app with Terraform and checked the logs the next morning. Every few minutes a warning appeared: “The Dashboard setting is no longer supported.” Nobody on the team had added a dashboard. When I opened the app settings, I found a setting named AzureWebJobsDashboard holding a full storage account connection string, including the account key.

That setting is the AzureWebJobsDashboard connection string, and it is a leftover from the first generation of Azure Functions. It does nothing useful on modern runtimes, yet templates and tools still create it. It also puts a powerful storage key in a place where many people can read it.

This guide explains what the setting was for, why it keeps appearing, and how to remove it safely. You will also learn how to stop your pipelines from re-adding it and how to replace it with Application Insights and Azure Monitor.

What the AzureWebJobsDashboard Connection String Is

The WebJobs dashboard was a web page that showed function and WebJob runs, logs, and invocation history. To feed that page, the runtime wrote log data into an Azure Storage account. The AzureWebJobsDashboard setting held the connection string for that storage account.

Two storage settings often get confused:

The first setting is essential. Microsoft states that AzureWebJobsStorage supports operations such as key management, timer trigger management, and Event Hubs checkpoints.

The second is obsolete. The Azure Functions team proposed removing dashboard support completely, saying it was “not something we’re maintaining,” and pointed customers to Application Insights and Log Analytics as the alternatives.learn.microsoft+1

On current runtimes, the host logs the warning “The Dashboard setting is no longer supported” whenever it finds the setting. The message is harmless to your code, but it adds noise to your logs and a secret to your configuration.

If you are new to the platform, start with what Azure Functions is. To see how settings reach your code, read about Azure Function app settings and how to access an app setting in Azure Functions.

Pro Tip: In my experience, the fastest way to tell whether a function app is “old” is to look for this setting. If it exists on a v4 app, someone copied an old template, and other legacy settings are probably hiding nearby.

Why the Setting Keeps Coming Back

Many teams delete the setting and find it again a few days later. Here are the usual sources.

Infrastructure templates. The Terraform azurerm provider adds AzureWebJobsDashboard by default, because its builtin_logging_enabled attribute defaults to true. Setting that attribute to false stops it.stackoverflow+1

Project templates. A Visual Studio Developer Community report from September 2026 says the Azure Functions template still generates AzureWebJobsDashboard even though modern isolated apps no longer use it. When it runs against Azurite, the console shows the “no longer supported” message.

Old ARM templates and scripts. Copy-and-paste habits spread the setting from project to project.

Portal and CLI creation flows. Microsoft’s original proposal notes that app-creation flows already left it off, so a setting that appears on a new app usually came from your own automation.

Why It Matters for Security

The connection string holds a storage account key, and a key grants broad access. Application settings are encrypted at rest, but anyone with access to the app’s configuration screen can read the value, and there is no access auditing like you get in Key Vault. A leftover key in an unused setting is a risk with no benefit.

Pro Tip: I treat every unused connection string as a finding in a security review. A secret that does nothing is still a secret someone can copy.

Check Your Runtime Before You Delete Anything

Do not delete the setting blindly. If your app still runs on the 1.x runtime, the dashboard may still be in use, and the correct fix is to migrate the app. Check the runtime version first.

az functionapp config appsettings list \
  --name <function-app-name> \
  --resource-group <resource-group-name> \
  --query "[?name=='FUNCTIONS_EXTENSION_VERSION' || name=='AzureWebJobsDashboard' || name=='APPLICATIONINSIGHTS_CONNECTION_STRING'].name" \
  --output tsv

This command lists the app settings for your function app and filters to three names. The --query parameter uses JMESPath to keep the output short, and --output tsv prints plain text. It prints names only, so no secret values appear on screen.

Next, read the version value itself:

az functionapp config a