We have a Slack webhook that's used to subscribe to a statuspage.io page for a 3rd party system we use. On a semi-regular basis, we get an email to the email address we used stating:
Hey,
We've detected a problem with your webhook endpoint subscribed to the [3rd party] status page, so we've deactivated the webhook.
Please make sure that your webhook endpoint of https://hooks.slack.com/services/[...] is responding with a 2xx response code within 30 seconds of initial connection.
Once you're confident you've addressed the issue preventing the webhook from completing successfully, you should visit the [3rd party] status page to re-subscribe the endpoint to continue using it.
I understand that it's fruitless having a system continuing to call a broken webhook endpoint, but given the frequency with which this occurs (plus the fact that Slack webhooks rarely seem to fail elsewhere) I wonder if the failure handling for broken webhooks on the statuspage.io is a bit too aggressive?
The manual process required to resubscribe the webhook every time this happens is quite a pain, and means that it often doesn't get done which reduces the value of the functionality.
@Leonard I tried creating a webhook from google chat into status page and I have the same error mentioned above, could you suggest why this might be happening.
@Leonard +1 request for Slack endpoints support
any updates on this?
We have a subscriber who wants notifications in a google chat and is getting the weboook deactivaton.