Aspnetcore.docs: Readiness and Liveness definitions contradict Google Cloud definitions

[OldrichDlouhy]

The Health Checks in ASP.NET Core documentation page states:

In some hosting scenarios, a pair of health checks are used that distinguish two app states:

• The app is functioning but not yet ready to receive requests. This state is the app's readiness.
• The app is functioning and responding to requests. This state is the app's liveness.

This seem to be opposite of what Google Flex Engine App documentation states:

• Liveness checks confirm that the VM and Docker container are running. App Engine restarts unhealthy instances.
• Readiness checks confirm your instance is ready to accept incoming requests. Instances that fail the readiness check are not added to the pool of available instances.

It may be worth noting this difference in the documentation.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: c0cbb094-29e9-740a-9fd6-db372641d753
• Version Independent ID: 52d8efc9-a336-71d9-6d90-98173cbf6bf4
• Content: Health checks in ASP.NET Core
• Content Source: aspnetcore/host-and-deploy/health-checks.md
• Product: aspnet-core
• Technology: aspnetcore-hostdeploy
• GitHub Login: @Rick-Anderson
• Microsoft Alias: riande

[Rick-Anderson]

@glennc great question. If you can provide a draft answer I'll help.

[guardrex]

This has been asked and answered several times. The definitions aren't in conflict based on prior analysis. I recommend finding and reporting the prior instances where this ask occurred and then asking Ryan to comment. I'll do it now ... I have a few minutes to pull those up.

[guardrex]

"Several times" ... actually, twice. :smile:

• https://github.com/dotnet/AspNetCore.Docs/pull/18662
• https://github.com/dotnet/AspNetCore.Docs/pull/18266

I checked on this against Kubernetes (linked on the second one :point_up:), and I didn't find such a great conflict as the Google text indicates.

@rynowak, do you want to ...

1. Do nothing ... stick to our guns here.
2. Change the topic's definitions of these terms. Side ❓ ... Was it wrong from the start and we didn't catch it? That seems unlikely based on how much work we've done on this topic.
3. Leave the topic's definitions alone but call out that the terms are defined differently by different industry groups.

[Rick-Anderson]

It's 2 or 3, ignore is not an option. 3 seems reasonable, hopefully adding, For more information, see [this GitHub issue](URL).

[guardrex]

Not an option unless Ryan says that he's correct and that _Google is wrong_ :trollface: lol.

IIRC, we had a brief word on it when the topic was being written. My weak memory (👴) is that he was happy with what he said at the time.

[guardrex]

btw on Option 2 ... it's not just the text. The sample app needs to change, too.

[guardrex]

cc: @unaizorrilla ... Would you like to comment on this, too? See the cross-linked remarks :point_up:.

[unaizorrilla]

Hi @guardrex

IMHO code and samples explaining readiness and liveness are ok but the text:

The app is functioning and responding to requests. This state is the app's liveness.

will be improved!!! liveness is about app functioning without checking dependencies ( database, cache etc ... ) , only check if the container is running but not ensure request can be sent. Unhealthy instances are restarted by orchestrators ( K8S, App Engine etc )

[guardrex]

Thanks @unaizorrilla ... then we only need to adjust the language and not the sample. If you don't mind, I'll ping u for a review of the PR.

@Rick-Anderson ... I'll work this ... It shouldn't take long.