Changing region and increasing timeout seconds for netlify functions


If under a pro plan, is it possible to change the region and increase the timeout limit for our netlify functions?

Thank you

Hey @heg-svcProntoCustome, this post might be of interest to you: [Common Issue] Functions 101 & Debugging.

Functions timeout after 10 seconds, and are limited to 1024mb (1 gb) of memory by default. They are deployed to AWS Lambda in their us-east-1 region. Some modules, for example, Headless Chrome , require the whole 1gb of RAM! There are custom settings available (up to 26 seconds runtime and 3Gb memory) which you’ll need to contact our support team - please post in the #admin area of this forum to get our attention for this.”

1 Like

@Pieparker, thanks for providing that link! That’s exactly what we would have recommended :smiley:

@heg-svcProntoCustome - it depends a little bit on what your needs are, can you tell us what kind of a timeout you might need?

1 Like

@perry Thank you for your reply, we are aware that the functions time out after ten seconds but because an external API we are calling are exceeding this time limit we would like to increase it to 26+ seconds. Furthermore, if we can change the aws lambda function service hosting to somewhere closer to where the external API are hosted (Australia), then it might speed up the response and prevent it from tieing out. Would you know how to request Netlify to increase the timeout and change where the functions are hosted?

You can change it to only 26 seconds; that is as long as we can permit within our infrastructure.

You can also run in any (single) region that supports lambda execution.

The way to request an upgrade is to:

  1. upgrade each site you need requested to Functions Level 1 (see - you get there from the “settings and usage” button on your Functions “tab”, from the main page on the site(s) in question)
  2. mention the site name or API ID (which is safe to share publicly) here, and we’ll make the settings change for you.
  3. you redeploy the function(s) in question to make them use the new setting. That deployment MUST change their checksum on disk, so adding a log line or something may be helpful in ensuring this happens.

@fool Hi, thank you for your reply!

I would just like to ask what you mean by being able to run in any single region. Does that mean we can change where the functions are hosted?

As we are having trouble with the timeout and we are not sure where the root of the problem is. Are we able to have the timeout increased to 26 seconds for only 2 days to check if it will solve the problem?

Thank you

Yes, you can pick any AWS region that hosts lambda functions:

Functions level 1 is $25/mo for each site, and that is what you must pay to use the increased timeout (and if you want, specific region).

@fool Thank you for your quick reply!

We have done some testing with postman and calling an external API. The time it took to call the API (hosted in Australia) from New Zealand is around 5s. But the netlify functions are taking around 9-9.6s to get the results from the external API. We are currently puzzled whether the functions are taking longer because of where the functions are being hosted (from the US to Australia, then back to the US again). Or because the external api we are calling are too slow. We are estimating that there is around a 4s overhead ( Assuming 2s to get from AUS to US, another 2s US back to AUS).

We would like to ask if this is normal? Would changing where the Netlify functions are hosted reduce the 4s overhead?


Hard to say for sure, but if you send us the value of a slow-but-succeeded-in-about-9-seconds HTTP header value for the header x-nf-request-id, we’ll be able to try to look that up for you.



We have upgraded the functions level to level 1. Are you able to extend the timeout to 26 seconds and also change the hosting location of the Netlify functions to Sydney Australia?

Our site name is: hegportal-dev-train, and our API ID is: a8496511-9156-4c72-a1d3-09d4f98da5ed.

Thank you.

Hi @heg-svcProntoCustome!

OK, so I have the hosting location for lambda functions in Sydney, but as far as I know, we have not used that region before and can’t be 100% that it will work. So I would like to ask if you wouldn’t mind testing this out on a test site first, before we set it up on hegportal-dev-train? We’d be happy to upgrade the test site for free :slight_smile:

Let me know if you’d be willing to test, and if so, please create and send us the test site name and we’ll set things up.

Hi laura (@laura)

Thank you for replying, the site itself is a test site (just to see if the geographical location will help with the speed). If you can just change the hosting location on hegport-dev-train then it would be swell!

Thank you

OK, sounds good to me! I’ve now changed the region and increased the timeout for functions on that site.

For the new settings to activate, you’ll have to redeploy your functions with a change in checksum - so maybe add some space to a log line or something that will make a change even if compressed (that won’t be optimized away during build).

Please update us on how it goes! :slight_smile:

Hi @laura

Thank you for your help! For adding a log line, do we need to apply this to every lambda functions? I have added a new console log onto each of our functions. I will be redeploying the functions now.


Hi, @heg-svcProntoCustome. Yes, the change must occur for each function that needs to be redeployed in the new region and/or with a new timeout.

We’re happy to answer if there are other questions.

Hi @luke

Thanks for replying,

Moving the function to Sydney has improved our situation.

Are there any packaged subscription for all sites/ID deployed under this account that can enable function level one across all sites that we deploy?

Is there also a setting such that the default for this account (reflective of all sites) is “increase timeout for 26 seconds” AND deploy functions to Sydney? We may have multiple sites and it can be labour intensive to request for each site we deploy.



We don’t have a package such as you describe. You’ll need to do that on a per site basis.