Warning state for health checks

[mderriey]

Hi,

What would you think of a third state for the health checks? The idea would be to have a Warning state. It wouldn't fail the outcome, so it would still return a 200 OK, but it could output information in the JSON response or in the logs if it's sensitive.

@robdmoore was thinking of having a check to verify if a certificate was about to expire. Failing the result doesn't make sense since it's not a fatal error, but surfacing potential issues would be nice.

Happy to take this one if you agree with the idea.

[BenPowerProfessional]

Not sure how that would be implemented, as the fail is invoked as an exception. Personally I wouldn't throw an exception ever in a warning situation.

I do agree more states might be useful however.

[uglybugger]

It's definitely worth some consideration. I'd also been planning to make the HTTP response code a bit more sophisticated - for instance, "Don't start routing traffic to me yet" is different to "Stop routing traffic to me." It's entirely possible that we want to return a 503 in the first instance and a 200 in the second, even if the reason for the failure is potentially the same.

As a first cut, a warning state wouldn't be a bad idea if you'd still like to have a go. We might end up changing the signature of the IHealthCheck.Check() method. I'd been trying to avoid that but if we need to do it then so be it :) I'd be thinking of returning an IEnumerable<IndividualHealthCheckResult>. It would be a breaking change but would mean relatively few code changes to health checks that have been implemented by other people.

Thoughts?

[jamesleech]

9 I gave this a short via throwing a Warning Exception within a HealthCheck.

• Means no breaking change
• Means the signature of the IHealthCheck.Check() hasn't been changed