Can Discourse Webhooks be used for reporting uptime to a 3rd party service e.g. hund.io ?
if so, How?
AI-generated summary
The discussion revolves around using Discourse’s /srv/status endpoint for uptime monitoring via third-party services like Hund.io or Uptime Kuma. itsbhanusharma initiates the query, seeking a way to report uptime to a public status page. Falco suggests using the /srv/status endpoint, which returns “ok” if the service is running. pfaffman shares a concern about reliability, noting that the endpoint may return “ok” even when the main site is down due to issues like 500 errors or misconfigured reverse proxies. Mittineague confirms that the endpoint may show “ok” during initial setup, but fails after reloading. tgxworld clarifies that /srv/status is intended for uptime checks, not full functionality. FrancescoM reports issues with Uptime Kuma failing to connect to the endpoint, despite working with other sites. itsbhanusharma suggests configuring the monitor to check for the “ok” keyword and disable SSL verification. FrancescoM continues troubleshooting, eventually resolving the issue by using the local Docker container hostname. itsbhanusharma advises running uptime monitoring from a separate server to avoid dependency on the same infrastructure.
If you just need to measure uptime, configure your tool to hit discourse.example.com/srv/status.
Exactly what I want! … as this is to report system uptime to someone visiting a public status page. I saw webhooks in the hund.io configuration page so I thought maybe that is something but I’ll try the Pingdom integration instead.
Thanks for help.
@pfaffman we are using Promethus Integration for advanced Stuff already … needed something to test discourse availability every few seconds and report to a 3rd party for a public status page. The solution by @Falco should work afaik but I’ll test and update how it goes.
Well, I don’t know whether I trust it.
https://community.yellowandblack.online/srv/status says OK, but https://community.yellowandblack.online/ returns a 500 error.
I tried it just now and got the “Congratulations” setup page.
But if you reload a few times, you’ll stop getting that. At least, that’s my experience.
/srv/status is meant for measuring uptime only and not whether the server is returning the right response.
I guess that depends on how you define “uptime”…
In a Layman’s term, Service is Properly functioning! e.g. if there is a 500 error then it should return something other than ok!
@pfaffman I can confirm that behaviour. My system runs behind a Nginx reverse proxy and I Get okay no matter what!
Olá!
Eu tentei usar o Uptime Kuma apontando para /srv/status, mas ele me retorna “Connection Refused” (Conexão Recusada).
Estou usando o Uptime Kuma em um contêiner, assim como o Discourse. Também, para ambos, estou usando o traefik como proxy reverso. O Uptime Kuma com outros sites funciona muito bem, mas não consigo acessar o aplicativo Discourse.
VocĂŞ pode me dizer o porquĂŞ?
Agradeço desde já! 
Isto é um pouco estranho, você pode compartilhar uma captura de tela de como você configurou? Você tem que configurá-lo como monitor de palavra-chave, procurando pela palavra-chave “ok” e código de status 200
Olá @itsbhanusharma e obrigado pela resposta rápida!
Eu configurei apenas o código de status, esta é a minha configuração
Eu também estou usando uma rede docker “proxy_network” para o Traefik.
Obrigado novamente pela sua ajuda!
o uptime kuma está hospedado na mesma máquina que o discourse?
EDIT:
Eu acredito que este seja o seu problema.
Olá,
sim, o servidor Ă© o mesmo.
Mas com outros websites funciona perfeitamente, o Ăşnico problema Ă© com o Discourse.
Talvez um resolvedor DNS interno?
Muito provavelmente Ă© uma incompatibilidade de certificado.
E o monitor de tempo de atividade não detectará problemas se o próprio servidor estiver inativo, portanto, é recomendado tê-lo em um servidor diferente daquele com o restante de suas aplicações.
Olá, obrigado pelo conselho.
O aplicativo Discourse tem um certificado SSL gerado pelo Traefik usando o Let’s Encrypt.
No momento estou usando a verificação do contêiner usando o socket do docker, mas não é confiável.
Posso tentar outra coisa? Eu tenho apenas um servidor com docker.
Obrigado novamente.
mude a configuração para monitorar a palavra-chave ok, desative a verificação ssl.
Mude o tipo de monitor para palavra-chave primeiro.