Hi @Joao Pedro Lopes,
Thank you for asking this question on the Microsoft Q&A Platform.
I hope that the following article can be of help to you:
The HTTP request length is limited to 100 MB (104,857,600 bytes), and the URL length is limited to 4 KB (4,096 bytes). These limits are specified by the httpRuntime
element of the runtime's Web.config file.
If a function that uses the HTTP trigger doesn't complete within 230 seconds, the Azure Load Balancer will time out and return an HTTP 502 error. The function will continue running but will be unable to return an HTTP response. For long-running functions, we recommend that you follow async patterns and return a location where you can ping the status of the request. For information about how long a function can run, see Scale and hosting - Consumption plan.
Function app timeout duration
The timeout duration for functions in a function app is defined by the functionTimeout
property in the host.json project file. This property applies specifically to function executions. After the trigger starts function execution, the function needs to return/respond within the timeout duration. For more information, see Improve Azure Functions performance and reliability.
The following table shows the default and maximum values (in minutes) for specific plans:
Expand table
Consumption plan | 5 | 10 |
Premium plan | 30<sup>2</sup> | Unlimited<sup>3</sup> |
Dedicated plan | 30<sup>2</sup> | Unlimited<sup>3</sup> |
<sup>1</sup> Regardless of the function app timeout setting, 230 seconds is the maximum amount of time that an HTTP triggered function can take to respond to a request. This is because of the default idle timeout of Azure Load Balancer. For longer processing times, consider using the Durable Functions async pattern or defer the actual work and return an immediate response.
<sup>2</sup> The default timeout for version 1.x of the Functions runtime is unlimited.
<sup>3</sup> Guaranteed for up to 60 minutes. OS and runtime patching, vulnerability patching, and scale in behaviors can still cancel function executions so ensure to write robust functions.
Make sure background tasks complete
When your function starts any tasks, callbacks, threads, processes, they must complete before your function code returns. Because Functions doesn't track these background threads, site shutdown can occur regardless of background thread status, which can cause unintended behavior in your functions.
For example, if a function starts a background task and returns a successful response before the task completes, the Functions runtime considers the execution as having completed successfully, regardless of the result of the background task. If this background task is performing essential work, it may be preempted by site shutdown, leaving that work in an unknown state.
Best regards,