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!
안녕하세요!
/srv/status를 가리키도록 Uptime Kuma를 설정해 보았지만 "Connection Refused"라는 오류가 발생합니다.
저는 Uptime Kuma와 Discourse 모두 컨테이너로 실행하고 있으며, 두 서비스 모두 traefik을 리버스 프록시로 사용하고 있습니다. Uptime Kuma는 다른 웹사이트를 잘 모니터링하지만, Discourse 앱에는 접근할 수 없습니다.
원인을 알려 주실 수 있을까요?
미리 감사드립니다! 
조금 이상하네요. 설정 방법을 스크린샷으로 공유해 주시겠어요? 'ok’라는 키워드와 상태 코드 200을 검색하도록 키워드 모니터로 설정해야 합니다.
안녕하세요 @itsbhanusharma, 빠른 답변 감사합니다!
저는 상태 코드만 설정했는데, 제 구성은 다음과 같습니다.
Traefik을 위해 "proxy_network"라는 Docker 네트워크도 함께 사용하고 있습니다.
도움 주셔서 다시 한번 감사합니다!
업타임 쿤마(Uptime Kuma)가 디스코스(Discourse)와 같은 머신에 호스팅되나요?
수정:
이것이 당신의 문제라고 생각합니다.
안녕하세요,
네, 서버는 동일합니다.
하지만 다른 웹사이트에서는 완벽하게 작동하며, 유일한 문제는 Discourse입니다.
내부 DNS 리졸버 문제일까요?
가장 가능성 높은 원인은 인증서 불일치입니다.
서버 자체가 다운된 상태에서는 업타임 모니터가 문제를 감지할 수 없으므로, 애플리케이션이 실행 중인 서버와 다른 서버에 모니터를 설치하는 것이 권장됩니다.
안녕하세요, 조언 감사합니다.
Discourse 앱에는 Let’s Encrypt를 사용하여 Traefik이 생성한 SSL 인증서가 있습니다.
현재 docker 소켓을 이용한 컨테이너 체크를 사용하고 있지만, 신뢰성이 떨어집니다.
다른 방법을 시도해 볼 수 있을까요? docker가 설치된 서버는 하나뿐입니다.
다시 한번 감사합니다.
설정을 변경하여 ok 키워드를 모니터링하고, SSL 검사를 비활성화하세요.
먼저 모니터 유형을 키워드로 변경하세요.