Timer trigger on Flex Consumption gets terminated early

Question

I have a function app with a timer trigger that runs every 2:nd hour. In the hosts file, the setting "functionTimeout" is set to "00:40:00" but the function is abruptly terminated after approximately 3 to 4 minutes and never runs to an end. Note that the next invocation is then at the scheduled time.

Is this a bug within the Flex Consumption implementation? According to the docs, the timeout should be 30 minutes as default and I should be able to specify a value of infinite.

Answer 1

For a Flex Consumption plan, the documented function execution timeout is:

• Default: 30 minutes
• Maximum: Unbounded (no enforced maximum), controlled by functionTimeout in host.json.

The early termination after 3–4 minutes is not expected behavior based on the documented limits. With functionTimeout set to 00:40:00 on Flex Consumption, the function should be allowed to run up to 40 minutes unless something else (for example, the function code, dependencies, or platform health) is causing failures.

The only hard 230‑second (≈3.8 minutes) limit mentioned in the documentation applies specifically to HTTP‑triggered functions because of the Azure Load Balancer idle timeout, not to timer triggers. Since this is a timer trigger, that 230‑second limit should not apply.

Given the documentation, this behavior is more indicative of an issue in the environment or platform rather than by-design timeout behavior for Flex Consumption. It aligns with a potential platform or host issue (for example, similar to cases where the host reports unhealthy or initialization timeouts), not with the documented functionTimeout rules.

To proceed:

1. Confirm the app is indeed on Flex Consumption (not Consumption) and that functionTimeout is correctly set in host.json at the root level.
2. Check Application Insights / logs for any host or worker process errors around the 3–4 minute mark.
3. If the configuration is correct and logs do not show an application‑level failure, treat this as a platform issue and open a support case with Azure Support, referencing the documented Flex Consumption timeout behavior.

---

References:

• Azure Functions hosting options
• Azure Functions Flex Consumption plan hosting
• Timer trigger for Azure Functions (programming-language-csharp)
• Timer trigger for Azure Functions (programming-language-javascript)
• Timer trigger for Azure Functions (programming-language-typescript)
• Timer trigger for Azure Functions (programming-language-python)
• Timer trigger for Azure Functions (programming-language-java)
• Timer trigger for Azure Functions (programming-language-powershell)

Answer 2

Hello Lennart !

Thank you for posting on MS Learn Q&A.

This should not be treated as a normal functionTimeout behavior.

For Flex Consumption, the documented default timeout is 30 minutes, and the maximum is unbounded. A value such as:

{
  "functionTimeout": "00:40:00"
}

should be valid for a non-HTTP timer-triggered function. For unbounded execution, the documented value is:

{
  "functionTimeout": "-1"
}

However, unbounded does not mean the instance can never be stopped. Flex Consumption still has platform behaviors such as scale-in, platform updates, app restarts, deployments or host/worker crashes. During scale-in, Flex Consumption should normally allow up to a 60-minute grace period, while platform updates have a 10-minute grace period. So if the function is being killed consistently after 3–4 minutes, it is probably not the configured functionTimeout itself.

Check that the deployed host.json really contains the timeout setting at the root level:

{
  "version": "2.0",
  "functionTimeout": "00:40:00"
}

Then check Application Insights or Log Analytics around the failed invocation for messages such as:

traces
| where timestamp > ago(24h)
| where message has_any ("DrainMode", "Stopping host", "Host shutdown", "Invocation canceled", "FunctionTimeout", "Worker process", "OutOfMemory")
| order by timestamp desc

Also check exceptions:

exceptions
| where timestamp > ago(24h)
| order by timestamp desc

If you see DrainMode, Stopping the listener, Invocation canceled, or host restart messages before the 40 minute timeout, then the function is being cancelled by host lifecycle behavior not by functionTimeout.

If the timer function calls an HTTP endpoint, also check whether the failure is actually coming from that HTTP call. The Azure Functions 230 secs limit applies to HTTP triggered responses, not to timer triggers, but downstream HTTP calls or client timeouts can make it look like the timer function was killed after about 3 or 4 minutes.

The reason the function only runs again at the next scheduled time is expected for timer triggers: timer triggers do not automatically retry after a failed execution so they run again on the next schedule.

If the logs show platform cancellation or DrainMode after only a few minutes, you should open support ticket.