Increase Response time limit for checks

Feature RequestSchedulingMay 17, 2023

💡 For general support requests and bug reports, please go to checklyhq.com/support

Is your feature request related to a problem? Please describe. We have a time out of apis defined at our load balancer level as 60 sec, checkly times out the request at 30 sec max with which we are not able to identify if the system is not responding or checkly servers not able to communicate with our servers.

Describe the solution you'd like Providing an option of custom timeout (maximum configurable to 100 sec)

Describe alternatives you've considered NA for now

Additional context NA

original GH issue link https://github.com/checkly/public-roadmap/issues/207

Posted by Tim Nolet · May 17, 2023

andyhinds

•

Jul 26, 2023

This functionality would also be very useful for us. We have APIs that often take longer than 30 seconds to complete and its a pain to have checks fail when there is no issue.

Regarding the payment aspect, a more predictable "a 90 second API check would come to 3 x the current API check cost" would likely be preferable but either would be fine if we could avoid these timeouts :-)

Tim Nolet
•
Jul 27, 2023
Hi Andy, thanks for responding. This is valuable information

Pete

•

Jun 8, 2023

This would be extremely useful for us as we run checks against a number of endpoints where the backend can take anywhere up to 3 minutes to respond due to the processing involved on the backend. When multiple checks fail due to the 30s timeout, it makes it harder to see at-a-glance what is really failing.

This timeout issue also means that the firewatch is less useful to us as we have to click into each test to see whether it failed due to the 30s timeout or a genuine error.

Tim Nolet
•
Jun 8, 2023
Hey @Pete, I understand the use case for long running API requests and also for longer running test cases using our Playwright checks. We are investigating some options, but it's hard for us to stretch the runtimes a lot without increasing price or at least charging for the extra runtime.

Essentially we have two options:
- Start charging by the second, with possibly some "free" seconds. This means your bill will be less predictable. The slower your backend, the more you pay us.
- Make longer runtime opt-in and charge per 30 second or 1 minute chunks. This means you can select what you want to pay for and predictably estimate your bill. For example a 90 second API check would come to 3 x the current API check cost.

Would love to here opinions on what the least friction would be, coupled with an understandable and predictable billing model.