MongoByte MongoDB Logo

Welcome to the new MongoDB Feedback Portal!

{Improvement: "Your idea"}
We’ve upgraded our system to better capture and act on your feedback.
Your feedback is meaningful and helps us build better products.

Add new feedback Subscribe
Status Started
Categories Atlas Triggers and Functions
Created by Guest
Created on Oct 28, 2019

RELATED FEEDBACK

Increase of Functions timeout

Timeout is set to 90 seconds. This value is a fixed setting and is too low for extensive ingestion functions. A default value of 600 seconds would be helpful. Even better would be the ability to set an individual timeout value per application in the settings.
  • Guest
    Apr 6, 2023
    The timeout is currently set to 240 seconds. Please see the article below to stay up to date with the latest on Function Constraints. https://www.mongodb.com/docs/atlas/app-services/functions/#constraints
    Reply
  • Guest
    Nov 16, 2021
    I notice the timeout recently went up from 90 to 120 seconds. I have some long-running intensive statistical functions that I have had to break up into manageable parts, saving state along the way. If the function times out I have a timer that calls it again (every 2 minutes) and picks up from where it left off.
    Reply
  • Guest
    Sep 8, 2021
    We definitely need the ability to extend the execution timeout or something else to run long-living tasks.
    Reply
  • Guest
    Sep 3, 2021
    90 secs as a default is good, but ability to adjust it as required would be super helpful. It would save a lot of time working around this limitation
    Reply
  • Guest
    Jun 9, 2021
    overriding of timeout for each application/trigger will be so helpful
    Reply
  • Guest
    May 3, 2021
    I personally appreciate the lower default so as to not consume resources unnecessarily. However, I fully support being able to override the default for executions which are known to potentially take a long time.
    Reply
  • Guest
    Jul 26, 2020
    This is especially helpful for running long-running batch jobs based on various Triggers. As an example, we run weekly batch jobs to generate reports, which can sometimes take longer than 90 seconds to execute and/or to orchestrate the entire batch. We've mostly worked around the issue by breaking the functionality into multiple functions and relying on asynchronous processing which are able to kick off many individual processes, but there is a limit to how much we can do this before having to move to a service like AWS Batch.
    Reply