# Particle Webhook Socket Timeout in Error Log

**URL:** <https://community.particle.io/t/particle-webhook-socket-timeout-in-error-log/51785>\
**Category:** Cloud\
**Tags:** electron\
**Created:** [August 20, 2019, 8:41pm UTC](https://community.particle.io/t/particle-webhook-socket-timeout-in-error-log/51785 "2019-08-20T20:41:44Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![d.chauhan](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/d.chauhan/32/19161_2.png) [@d.chauhan](https://community.particle.io/u/d.chauhan)\
**Post date:** [August 20, 2019, 8:41pm UTC](https://community.particle.io/t/particle-webhook-socket-timeout-in-error-log/51785/1 "2019-08-20T20:41:44Z")

</div>

Hey All,

What does this error message **ESOCKETTIMEDOUT** mean? I have multiple electrons sending data every few minutes. All these incoming data triggers a webhook to send data to AWS endpoint. Sometimes few messages return with the above Error message. I am not sure if this is particle issue or AWS issue.

 ![image](https://us1.discourse-cdn.com/flex026/uploads/particle/original/3X/2/0/209ccc8fd7f20b918b6995097a4418d227257435.png)

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [August 20, 2019, 8:46pm UTC](https://community.particle.io/t/particle-webhook-socket-timeout-in-error-log/51785/2 "2019-08-20T20:46:41Z")

</div>

As a rule of thumb, chances are that a lot of questions new users may face have been raised and possibly answered in the past already. Hence one of the steps before raising a question would be to search the forum (see Step 2 in that thread)  
[https://community.particle.io/t/welcome-using-particle-forums-and-forum-etiquette](https://community.particle.io/t/welcome-using-particle-forums-and-forum-etiquette)

This might be worth a read

> [@What does ESOCKETTIMEDOUT mean?](https://community.particle.io/t/what-does-esockettimedout-mean/29100):
>
> Hi, {"name":"hook-error/pushtemps/0","data":"ESOCKETTIMEDOUT","ttl":"60","published\_at":"2017-02-03T03:08:02.706Z","coreid":"particle-internal"} Does it mean the upstream webhook destination timed out? Does it mean it couldn’t send the response to a downstream photon? Why aren’t there transaction ids to link hook-sent with hook-error or hook-response? Mark

---

<div class="post-metadata">

**Author:** ![mterrill](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mterrill/32/5149_2.png) [@mterrill](https://community.particle.io/u/mterrill)\
**Post date:** [September 17, 2019, 5:37am UTC](https://community.particle.io/t/particle-webhook-socket-timeout-in-error-log/51785/3 "2019-09-17T05:37:25Z")

</div>

Yeah mate, though the terrible thing about raising my old thread years later is:

- The documentation hasn’t been updated, and no best practice architecture has been provided.
- A indefensibly naive system is still in place where retries occur when a webservice returns a 500 etc. Eventually bringing down the webservice. The web standards way of doing it would be to terminate the particular webhook that error’d as you know, it could be the webservice saying the device isn’t allowed to make that call.

It’s why I’m moving away to a Google IoT stack.

@d.chauhan my recommendations:

- Never return anything but a 200 to Particle, it will eventually DoS your webhooks. Either:  
– Only only return 200 status codes, easy to do if you’re using say Google Cloud functions. Put an error message in description, but for the love of god use a 200 code or Particle will blow up.  
– Proxy everything through Amazon HTTP gateway, simple reason is you could then use third parties who do sometimes return 500’s like you’d expect to in the 20th century, but then you can force the response code on return traffic within the HTTP gateway status codes mangler.

- Use a job system, don’t send notifications etc via your webhook. Register a job to send a notification then return completed. Let your job system handle the actual long processing etc. I use Firebase realtime db in conjunction with google cloud functions.
