A deleted trigger in a C# function app ran a week after it was removed during the next deployment of the function app

Question

A deleted trigger in a C# function app ran a week after it was removed during the next deployment of the function app

Bonner Earle 0

We have a C# function app.

It had a single timer trigger.

We added a second timer trigger on a different schedule. We deployed this.
We removed the first timer trigger. We deployed this.

Azure only listed the second timer trigger.

On the next deployment of the app after the one that removed the first timer trigger (a week later) the first timer trigger ran during the deployment (terraform deploy during the terraform apply which happens before uploading the latest version of the C# function binaries)
The function app is hosted on a dedicated app service plan, it is configured to be a single instance

Various questions

Why is Azure running deleted timer trigger schedules?

Where is it getting the code to run the timer trigger that hasn't existed for a week?

Does deleting the folder
Blob containers -> azure-webjobs-hosts -> timers -> <your function name> -> Host.Functions.<your trigger name>
which contains a file with the next scheduled run time for the trigger in the storage account for the function stop this from happening?

Pravallika KV 14,640 Reputation points Microsoft External Staff Moderator

2026-05-06T13:43:48.3133333+00:00
Hi @Bonner Earle ,

Thanks for reaching out to Microsoft Q&A.

Here’s what’s happening under the covers:

Timer metadata lives in your storage account under the blob container azure-webjobs-hosts/timers/<FunctionAppName>/Host.Functions.<OldTriggerName>.status.json. That JSON file holds the “next run” timestamp for your old timer.

When you run terraform apply, ARM changes (app settings, plan, etc.) get applied first, which causes the Function App to restart and at this point your new binaries haven’t been pushed yet. The Functions host is still loading the old package and reads that status blob, so it happily fires off the “deleted” trigger one more time.

After the restart/triggers fire, Terraform (or your CI/CD) then uploads the new DLLs or package which finally removes the old function class but by then your old timer has already executed.

Follow below steps to prevent this:

Clear out the old timer metadata before or during deploy:

Delete the folder azure-webjobs-hosts/timers/<FunctionAppName>/Host.Functions.<OldTriggerName> in your function’s storage account. That removes the persisted “next run” checkpoint so the host won’t schedule it.

Deploy code first, then restart:

If you’re using WEBSITE_RUN_FROM_PACKAGE, point that setting at your new package before you trigger a restart. Or use “Remove additional files at destination” in your deploy so the old DLLs (and their triggers) don’t linger.

Or orchestrate a clean restart:

Stop the Function App via API/CLI

Delete the old blobs under azure-webjobs-hosts/timers

Push your new package

Start the Function App again

That way the host only ever sees your current timers.
Pravallika KV 14,640 Reputation points Microsoft External Staff Moderator

2026-05-07T09:05:03.2066667+00:00

Hi @Bonner Earle , following up to see if you had a chance to check the above response and if it was helpful. Please let me know if you have any questions.

1 answer

Your answer

Pravallika KV 14,640 Reputation points Microsoft External Staff Moderator

2026-05-06T13:43:48.3133333+00:00

Hi @Bonner Earle ,

Thanks for reaching out to Microsoft Q&A.

Here’s what’s happening under the covers:

Timer metadata lives in your storage account under the blob container azure-webjobs-hosts/timers/<FunctionAppName>/Host.Functions.<OldTriggerName>.status.json. That JSON file holds the “next run” timestamp for your old timer.

When you run terraform apply, ARM changes (app settings, plan, etc.) get applied first, which causes the Function App to restart and at this point your new binaries haven’t been pushed yet. The Functions host is still loading the old package and reads that status blob, so it happily fires off the “deleted” trigger one more time.

After the restart/triggers fire, Terraform (or your CI/CD) then uploads the new DLLs or package which finally removes the old function class but by then your old timer has already executed.

Follow below steps to prevent this:

Clear out the old timer metadata before or during deploy:

Delete the folder azure-webjobs-hosts/timers/<FunctionAppName>/Host.Functions.<OldTriggerName> in your function’s storage account. That removes the persisted “next run” checkpoint so the host won’t schedule it.

Deploy code first, then restart:

If you’re using WEBSITE_RUN_FROM_PACKAGE, point that setting at your new package before you trigger a restart. Or use “Remove additional files at destination” in your deploy so the old DLLs (and their triggers) don’t linger.

Or orchestrate a clean restart:

Stop the Function App via API/CLI

Delete the old blobs under azure-webjobs-hosts/timers

Push your new package

Start the Function App again

That way the host only ever sees your current timers.
Pravallika KV 14,640 Reputation points Microsoft External Staff Moderator

2026-05-07T09:05:03.2066667+00:00

Hi @Bonner Earle , following up to see if you had a chance to check the above response and if it was helpful. Please let me know if you have any questions.

Answer 1

What you are experiencing appears to be related to how Azure Functions manages timer triggers. Timer triggers in a function app rely not only on the code in your deployment but also on state stored in the Azure Storage account associated with the function app. Specifically, the runtime uses a hidden mechanism to persist schedules and "next run" information in the azure-webjobs-hosts container under the timers folder. This allows the runtime to track when timers should fire, even across restarts or redeployments. If a timer function is removed from your code but the corresponding state in the storage account remains, the runtime can still read the persisted schedule and execute the function, attempting to honor the last known configuration. Essentially, the runtime doesn’t automatically delete this state when the code is removed, which is why a deleted timer can run unexpectedly.

The code being executed comes from the version of the function binaries currently deployed in the function app's wwwroot. If your deployment process involves uploading new binaries after Terraform completes the apply phase, there can be a brief window where the runtime still has the old binaries in memory or on disk while it reads the timer metadata from storage. This explains why the deleted timer ran: the host read its schedule from storage before your latest binaries replaced the previous ones, so it executed the old code.

Deleting the corresponding timer metadata file in Blob containers -> azure-webjobs-hosts -> timers -> <your function name> -> Host.Functions.<trigger name> does stop the runtime from scheduling that specific timer. The runtime uses this file to determine the next run, so removing it effectively clears the timer’s schedule. You need to be aware, though, that simply deleting the file won’t prevent execution if there are still cached binaries in memory during deployment; this is mainly a safeguard against persisting schedules for removed timers. In practice, cleaning up the timer metadata when deleting a timer function ensures it won’t resurrect unexpectedly.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Share via

A deleted trigger in a C# function app ran a week after it was removed during the next deployment of the function app

1 answer

Your answer