Skip to main content

Has anyone found/documented a timeout on an app event? How long does the monday.com server wait for our 200 (or other) response before dropping the connection when it sends us a webhook for a workflow block?


Basically, how long do we have to complete (including any complexity retries) and return with a status code and body (including severity code, notification text, notification title, etc.) before the monday server drops the connection and starts retrying the event?


Providing appropriate responses is also impossible if we need to use a queue (per best practices) for mutations - there is no way to know the outcome of the mutation (easily) to respond with an appropriate status/error (referring to the new error mechanism that can disable a recipe, etc.), so we have to hold this connection and just wait for retries until near timeout - then queue them.


But what is the official monday timelimit for us to respond?

Hi @anon29275264,


According to these documents (search for the word “retry” in the monday developers website), it will retry every minute for 30 minutes.

monday apps framework

Hey @anon29275264 It is 60 seconds.


If your server does not return a success response within 60 seconds it will retry the request. If you return a failure response, it will also retry the request again. Like GCavin mentioned, it will continue to retry the request for 30 minutes.


If you are looking to implement a queuing system, you might need to consider OAuth instead of Seamless as it is unlikely that you can ensure your job will be completed within the 60 second expiration limit of the access token.


However, using Seamless, if you receive a complexity error or similar, you can simply return a failure response and the request will be retried again and the complexity should be free given it resets every minute. Using Seamless auth, you probably won’t required a queue. Note that if you have multiple mutations in a single action, you may need a method to check if a previous mutation has run successfully otherwise you may end up with duplicate items being created for example.


There was some talk a little while back about implementing a method to handle your app returning a 429 status code, and it will be retried for a longer period of time until your server can process the request, however i’m not sure of the latest update on this.

Reply


Terms & ConditionsCookie settings