Validating Azure Function Application Setting Configuration, fail to trigger

One of the most common reasons that an Azure Function is not triggered as expected is because the endpoint which notifies the Function to run is misconfigured or blocked for some reason.  The scenario I am focusing on here usually occurs during testing or after a deployment.  If you are doing or have done neither of those then this article won’t help in your scenario.

Let’s first make the connection between all the dependencies.  Take a look at Figure 1.


Figure 1, Azure Function endpoint configuration

Although this example targets a Blob Container, the concepts applies to Event Hub, Service Bus, Cosmos DB, Queue Storage, etc.…  In every case the function.json file will contain the binding information and the name of the Application settings that contains the trigger endpoint.  The value for the Application setting is often referred to as a connection string, because it provide the information about the address location and the credentials required to make the connection.  The content in the local.settings.json file is used for local development and testing, it contains a matching name and a value that provides connection information.

Causes for this to fail or become in valid

Here are a few reasons:

  • The Application setting does not exist or is empty
  • The endpoint no longer exists
  • The access key was changed
  • Spelling mistake
  • Network restriction

The Application setting does not exist or is empty

In this example, the Application setting is named myazurefunctionsstorage_STORAGE, you can see it in the blue box in Figure 1.  If that Application setting doesn’t exist on the Configuration blade for the given Azure Function, then the Function will not trigger.

The endpoint no longer exists

In this example, the endpoint is an Azure Storage account named myazurefunctionsstorage.  It have an endpointsuffix value of  If myazurefunctionsstorage is deleted for some reason, the Azure Function will not be triggered.  That won’t likely happen, because if it did, you would be able to upload anything and therefore wouldn’t expect the Function to trigger…  Which brings up another great point, in that, make sure you are uploading to the correct Azure Storage account, or Event Hub, Service Bus, etc.…  For example, if you are uploading a blob to mynewazurefunctionsstorage but the value for the Application setting is myazurefunctionsstorage, then your Function will not be triggered.

Additionally, notice that the path is blobcontainer.  It is more probable that the path is removed than a Storage account, the path, aka container needs to exist in the bound Azure Storage account.  You see the link in Figure 1 in green.

The access key was changed

Notice in Figure 1, the content within the purple boxes.  Again, this is the Connection string that identifies the connection information and credentials.  You will see something named, AccountKey.  This is a key which is required to connect to the Storage account.  If this changes or is invalid, then your Function will not trigger.

Spelling mistake

Well, yes, if you have read up to here, then you would know that would cause some issue.  If you intended to enter myazurefunctionsstorage but instead entered myazurefunctionstorage, then your Function would be triggered.  Just looking at those, it is kind of hard at first glance to see the mistake.

Network restriction

Many Azure products which can be bound to an Azure Function and get triggered support Network restrictions.  For example, Network Security Groups (NSG), Firewall, IP Restrictions and Private Endpoints.  If you implement any rule to restrict access to your triggering product, then the Function will not be able to access it and process your data.  If you implement any restrictions, you need to be certain to allow access to the Function.  Have a read of this article, Frequently asked questions about networking in Azure Functions.