Health check API

Contribute Feature

AI-generated summary

The discussion revolves around the need for a health check API in Discourse. axil suggests this after experiencing issues with an update that caused 500 errors, but a simple curl command returned a 200 status. codinghorror points out the existence of the /srv/status endpoint, but michaeld and sam explain that this endpoint only checks if the app’s middleware stack is working and may not catch more complex issues like database migration problems.

sam recommends monitoring 200 status codes and alerting on non-200s for a more reliable measure. downey asks if pointing an uptime monitor at https://discourse.example.org/srv/status would be sufficient and suggests expanding the components listed on this endpoint in the future. sam suggests alternative methods, such as checking a specific topic for text, and downey proposes a more detailed status check, listing individual components as “ok” or not.

1

It would be nice to have some sort of health check API. We recently faced an issue with an update and Discourse was producing 500 errors.

However, curl returned 200:

curl -I https://forum.gitlab.com
HTTP/2 200
server: nginx
2 Likes
2

This exists, see

/srv/status

15 Likes
3

Ah, thank you! I was searching “health check” and that didn’t yield any results.

2 Likes
4

Post is 404. What are the endpoints?

5

I’ve updated my post.

2 Likes
6

Actually I don’t think /srv/status would catch migration issues like the one mentioned above…

(and it would be pretty hard to build a check that does catch issues like that one)

2 Likes
7

Yes… /srv/status is there as a very cheap test, all it does is ensures the apps middleware stack is working.

To catch issues where you auto deploy I would recommend monitoring 200s, if there is a large increase in non 200s alert.

5 Likes
8

Would https://discourse.example.org/srv/status be a good place to point an uptime monitor? I am thinking it may not be enough to have a reliable measure of “is the site up”, but it would be nice to have something that produces less load on the system for monitoring purposes.

(Alternatively, might there be any plans to expand the components listed on this endpoint?)

3 Likes
9

Yeah that is a reasonable spot, you could also point at a specific topic and search for text if you want something more fancy

7 Likes
10

Yeah, we had been using /about but inclined to use this instead.

My old ops/on-call mind woke up to make me think it could still be interesting (and helpful occasionally for troubleshooting) if it were something like:

db ok
middleware ok
whatever-else ok
...
all systems ok
4 Likes