Include small response body in notifications directly
I typically implement a health check/status endpoint in my services, so it will return both a JSON response, and a valid HTTP status code (eg. 200 on success, 500 on error, for example).
Thing is, when I use this in combination with updown.io, I only get notifications that specify the reason based on the error code, eg. "Internal Server Error".
What I'd really want here is to have at least the Slack notifications include the entire response, or even just part of the response.
I'd even be fine if it only worked like this when you use the "contains" functionality, instead of relying on the HTTP status code, I just really, really want and need this feature.
This has just been deployed. You’ll now find in your down alert email an extract of the response alongside the string you configured for search in updown (that was already present before). There will also be a more visible link to the details page (to check the complete response received).
-
Pauli Jokela commented
There's an issue with the current implementation though: the parsing doesn't handle things like quotes well, so while it does include the string in the email, the Slack payload's embed ends up looking like this: \"status\":\"ok\"”
Additionally the webhook still doesn't include the snippet of the actual server response, which would be extra useful and actually what I was originally looking for.
Essentially I want to track two things with this:
- When the server is actually down/unresponsive
- When the server is reporting issues directly (combination of status code and status message)The status message here would be the most important one, as it would clearly describe what the actual issue is.
Generic "downtime" messages are very confusing, when you don't immediately know if the service is actually down or just reporting issues with something else.Note that simply including the server response in the custom webhook payload would be enough, as I could then write a wrapper to handle the formatting etc.
-
Olaf Lederer commented
A small snippet might be helpful if the whole pages is actually an error message (database connection error, php fatal error). Maybe you can add only those errors into the alter message.
They are never bigger than 1KB and indicate a huge problem.
It could be also combined with the given string for a test. If you parse the HTML for the given string, you could expand the the string a little bit and add this string to the alert message. -
Ok thanks, I'll see what I can do
-
Pauli Jokela commented
Thank you for the swift reply!
The idea here was definitely more along the lines of your latter response regarding the response body, and while in my case this is always JSON, which you can see an example of below, I'd be more than happy with plain-text as well.
Putting a hard limit on the character length should be fine as well, as long as it wasn't too small to begin with.Example from a backend application's health check endpoint (status changes to properly reflect the current state):
{"status":"ok","environment":"testing","version":"0.10.17.a782f86"}So in this case, I'd then check if the response contains the "ok" status, and if not, it would show the plain-text response, instead of "could not find string X".