azure function pipeline when trigger through schedule het struck

Hi @auraplus auraplus

Thank you for reaching out to Microsoft Q&A.

When an Azure Function is triggered through a schedule (Timer Trigger) and remains in a running or stuck state, but the same function completes successfully when triggered manually from the Azure portal, the issue is typically related to runtime behavior and execution context differences, not the function code itself. Scheduled executions run automatically on the Azure Functions host and are subject to conditions such as cold starts, locked or overlapping timer executions, storage lease dependencies, long-running operations, or dependency access delays. Manual executions from the portal usually run on a warm and already-initialized instance, which is why the function completes successfully when started manually but not when triggered automatically.

Refer below points to resolve this issue or this is the workaround:

Cold start or function app not warmed up

• Timer-triggered functions may run on a cold instance, especially on Consumption or Flex plans.
• Manual execution from the portal warms up the function app first, allowing faster startup and completion.
• Heavy startup logic (SDK initialization, database connections, Key Vault access) can cause scheduled runs to appear stuck. Workaround: Enable Always On (if using an App Service plan) and minimize startup logic.

Previous timer execution is stuck or overlapping

• Timer triggers rely on a storage-based monitor to ensure only one execution runs at a time.
• If a previous execution did not finish cleanly, future scheduled runs will wait indefinitely. Check configuration in host.json:

    {
      "extensions": {
        "timers": {
          "useMonitor":
  

• Review Application Insights logs to confirm whether an earlier execution is still running.

Long running or blocking execution logic

• Long-running operations, synchronous blocking calls, or infinite waits can prevent the runtime from marking execution as completed.
• Manual runs may succeed because the app is already warm and executes faster. Workaround: Ensure the function exits cleanly and consider using Durable Functions or a queue-triggered pattern for long-running tasks.

Dependency or Managed Identity access issues

• Scheduled triggers run fully under the function app’s managed identity and runtime permissions.
• Manual runs may succeed due to cached tokens or previously established connections. Check and validate: Managed Identity permissions, Key Vault access, storage access, and external service availability.

Azure Storage lease or connectivity issues

• Timer triggers depend on Azure Storage (via AzureWebJobsStorage) for scheduling and execution locking.
• Storage throttling, firewall rules, private endpoints, or DNS issues can cause the trigger to hang. Workaround: Verify storage connectivity, firewall/network rules, and review storage diagnostics.

Function timeout configuration

• On Consumption or Flex plans, exceeding execution time limits may stop the function before completion.
• Manual runs may complete due to reduced startup overhead. Check in host.json:

    {
      "functionTimeout": "00:10:00"
    }
  

Hello !

Thank you for posting on Microsoft Learn Q&A.

If it runs manually from the portal but gets stuck only on the schedule, I don't think that the code itself is the main problem because when you do the execution manually of timer triggered function it will use a separate manual invocation path while if you are dealing with a scheduled the run will depend on the timer listener if being correctly registered.

What I found is that Azure says trigger changes sometimes need a manual sync so restarting the function app performs a background trigger sync and there is also a syncfunctiontriggers API and I think this is especially relevant with some deployment methods like external package URL loccal Git or FTPS.

Also timer triggers use a storage lock so only one timer instance runs. If 2 function apps share the same storage and end up with the same host ID, only one timer may run or the host can stop. Azure documents this explicitly and recommends separate storage accounts or the host id

One of the issues I ecountred was the timezone since the timer cron uses utc by default. If you expected local time and didn’t configure timezone correctly, it can look like the schedule is not firing. In my case I found out that WEBSITE_TIME_ZONE is not supported on Linux consumption or Flex consumption and Microsoft notes it can even cause SSL and metrics issues there.

So what you can do is to check whether another app shares the same storage account and may have a host ID collision. The app insights or the og stream for that run that never finished can help you because the timer won’t fire again while one invocation is still outstanding.