I am currently making an integration with Zendesk using webhooks, everything was working fine and data was coming through on my website for about 2330 requests.
However suddenly the webhooks stopped working.
On further inspection I noticed the webhook had been disabled automatically, because of many Net::ReadTimeout errors.
I find it strange that the data is still coming through to my website just fine, but it getting a Net::ReadTimeout response nonetheless? What could be the cause of this?
Hey Bryan, thank you for the response.
I added a queue to my project and everything seems to be in working order!
Thank you!
Hey Sander - so glad to hear you got things working. I see that this is your first post - welcome to the Zendesk Community!
Is it possible to extend that 10 seconds period for considering an HTTP call timed out? We're experiencing issues with that behaviour.
Hi @Jon I. -- confirming that as mentioned in Notifying external targets that the timeout is indeed 10 seconds and can't be changed. Because target calls happen in a synchronous manner with triggers, it was determined that anything longer would have an overall negative impact and could lead to issues when saving tickets.
The recommendation for target calls that might take longer is to convert them to a job based services, so the call immediately returns. The Zendesk instance can then continue to subsequent operations without having to wait.
The next question might be then how can response data be read and processed by a Target call. Today, it can't unfortunately. However, the entire Target area is being reviewed to address these kinds of short comings. No details or release timeframes announced, but wanted to let you know that this area is being looked at for improvements.
Hope this at least sets expectations!
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
HTTP Targets have a fairly short timeout period. The request can go through, but the Zendesk side of the request only waits 10 seconds for a response. After 21 consecutive failures, the Target is disabled. See Avoiding timeout errors for more.
The short timeout is because Targets are executed during ticket update operations via triggers, so a long delay could have other side effects. If more time is needed by an HTTP Target, the recommendation is to have your HTTP Target's API use a job based/asynchronous approach rather than a synchronous approach.
If that doesn't seem to be what's happening Sander, please feel free to submit a ticket, so your particular account's situation can be looked at in detail.