[GH-ISSUE #569] Webhook timeout #414

New issue

Closed

opened 2026-02-25 23:42:22 +03:00 by kerem · 3 comments

kerem commented

2026-02-25 23:42:22 +03:00

Owner

Originally created by @Sa6SFKPH8 on GitHub (Oct 12, 2021).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/569

Is there a way to set the timeout length for webhook integrations?

We have established a webhook to an internal service that works perfectly. The notification is sent and received 100% of the time. However when testing the webhook, 95+% of the time, the system indicates that the test failed and the integration is broken (screen capture attached). Very rarely, the system does acknowledge the test as successful so this appears to be a timeout issue.

Finally, thanks for an immensely useful and elegant platform.

Originally created by @Sa6SFKPH8 on GitHub (Oct 12, 2021). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/569 Is there a way to set the timeout length for webhook integrations? We have established a webhook to an internal service that works perfectly. The notification is sent and received 100% of the time. However when testing the webhook, 95+% of the time, the system indicates that the test failed and the integration is broken (screen capture attached). Very rarely, the system does acknowledge the test as successful so this appears to be a timeout issue. ![2021-10-12_16-18-05](https://user-images.githubusercontent.com/7023234/137041775-4148f2d7-dc5f-4e29-9fa4-5c22fd3f2aee.jpg) Finally, thanks for an immensely useful and elegant platform.

kerem closed this issue

2026-02-25 23:42:22 +03:00

kerem commented

2026-02-25 23:42:22 +03:00

Author

Owner

@cuu508 commented on GitHub (Oct 13, 2021):

The timeout is for outgoing webhooks is 5 seconds and currently cannot be changed.

My concern with raising webhook timeout is that slow webhooks can block other outgoing notifications. There is a fixed number of worker processes working through outgoing notifications. If they all are busy waiting on a slow-to-respond webhook, then other notifications get delayed.

What is the typical response time, and what would be the optimal timeout value for your webhook?

@cuu508 commented on GitHub (Oct 13, 2021): The timeout is for outgoing webhooks is 5 seconds and currently cannot be changed. My concern with raising webhook timeout is that slow webhooks can block other outgoing notifications. There is a fixed number of worker processes working through outgoing notifications. If they all are busy waiting on a slow-to-respond webhook, then other notifications get delayed. What is the typical response time, and what would be the optimal timeout value for your webhook?

kerem commented

2026-02-25 23:42:22 +03:00

Author

Owner

@Sa6SFKPH8 commented on GitHub (Oct 13, 2021):

The response time in our case is very close to 5 seconds which is probably why it occasionally succeeds. It is never more than 10 seconds when successful, but that will not be universally applicable.

@Sa6SFKPH8 commented on GitHub (Oct 13, 2021): The response time in our case is very close to 5 seconds which is probably why it occasionally succeeds. It is never more than 10 seconds when successful, but that will not be universally applicable.

kerem commented

2026-02-25 23:42:22 +03:00

Author

Owner

@cuu508 commented on GitHub (Oct 14, 2021):

I've now changed the timeout to 10 seconds and changed the retry logic to cap the max time spent to 20 seconds.

Start timer
Run the initial HTTP request with timeout=10
If the initial request fails or times out, retry with timeout=10
If the retry also fails or times out, and we have spent less than 10 seconds since starting the timer, run the second retry with timeout=10.

In other words, the last retry may or may not run depending of how much time was spent on the initial try and the first retry.

@cuu508 commented on GitHub (Oct 14, 2021): I've now changed the timeout to 10 seconds and changed the retry logic to cap the max time spent to 20 seconds. 1. Start timer 1. Run the initial HTTP request with timeout=10 2. If the initial request fails or times out, retry with timeout=10 3. If the retry also fails or times out, **and** we have spent less than 10 seconds since starting the timer, run the second retry with timeout=10. In other words, the last retry may or may not run depending of how much time was spent on the initial try and the first retry.