Feature idea: Warnings (or notices) that show as warnings on the page but still cause it to return a 200

[violuke]

Firstly, thank you for the great package and the recent excellent update. It's a real improvement on an already extremely helpful package.

We would like to be able to raise warnings from individual health checks. We would like these clearly shown on the page (maybe in orange rather than red), but importantly, they should still result in the page returning a 200 (rather than a 500).

We currently have some "daytime-only" health checks. Essentially, these are things that we want to know about in the day (while we're awake), but we don't want to wake us up in the night (we use BetterStack monitoring to wake us up). These are things that can be dealt with the next morning.

At the moment, we have some time checking logic and skip these checks completely when it's not daytime, but this means that if there is an issue with one of these and we happen to be reviewing the health check results, we don't realise. Sometimes, a normal 24/7 check raises the alarm, but we don't see the added context that a daytime-only check is also failing, as the whole check is being skipped. This context would be really useful.

My suggestion is that the daytime-only part is probably pretty specific to us, so we can keep our existing daytime-only logic, but instead of skipping checks completely, we raise a different exception instead. I know there is a ServiceWarning which would have been a great candidate, but that would be a breaking change for others, so maybe there is a new ServiceNotice exception that renders this warning in the page, and we raise this instead of ServiceUnavailable when we want to see the notice but still get a 200 response.

I'd love to know your thoughts on this and see if you have an appetite for something like this. Would you accept a PR for this?

[codingjoe]

Hi @violuke,

Thank you for reaching out and offering to contribute. I truly appreciate that you took the time to write a thoughtful issue instead of having a bot send me 100 pull-requests ;)

Before version 4 this was an option, but it has been removed to reduce the project's complexity. But not without replacement (be it not documented).

Since version 4, you can easily add as many health endpoints as you desire. I'd encourage you to add one for each use case. e.G. I have one for the container health, one for all my platform providers, and one for my actual full application health. My Pingdom snitch is set up to monitor the latter.

The platform provider check, which includes EVERYTHING, including things like GitHub and other parts of the CI/CD pipeline. Here I mainly use the RSS feed and have that report into Slack.

So, I get "GitHub isn't working" updates in Slack all day long, but SMS at night when sh*t really hits the fan.

I still want to write a proper cookbook, but I haven't found the time yet. You are welcome to contribute more documentation and suggest further enhancements.

Cheers!
Joe

[violuke]

Thanks for the response, Joe! We recently upgraded to v4, and it didn't occur to me at that time that we could solve this situation (which we've had long before v4) with the new ability to create multiple endpoints! I think this is a great idea and should work for us 👍

Thank you

[codingjoe]

Thank you for your kind words. How wonderful to hear that this approach works for you. If you run into any issue, please reach out any time :)