From your laptop, open Powershell and run "docker container ls". Find the container listed with an unhealthy status.

Open Docker Desktop and select the container that is unhealthy (In your case it is CD container). Note: An unhealthy container may not appear unhealthy within the Docker desktop which is why the previous "ls" command is so critical.

Check the logs. It will most likely be running the health check periodically and it will write the attempt to the logs. Here is an example of a failing CM health check:

GET /healthz/ready - 80 - ::1 Mozilla/5.0+(Windows+NT;+Windows+NT+10.0;+en-US)+WindowsPowerShell/5.1.17763.2268 - 500 0 0 35126

Notice that the health check is trying to visit /healthz/ready and is receiving a 500 status code. This means our application is experiencing a YSOD but we cannot see it in the Sitecore logs (because Sitecore cannot even start).

Next, issue this command in the shell to view the raw output:

curl http://127.0.0.1/healthz/ready

This very quickly showed me that I had a bad reference pushed and I cleaned it up.

A similar approach can be utilized on all container types. Each container may have a slightly different health check, but this approach gets directly to the root of the problem. The previous answers are just guesses on common issues.

From your laptop, open Powershell and run "docker container ls". Find the container listed with an unhealthy status.

Open Docker Desktop and select the container that is unhealthy (In your case it is CD container). Note: An unhealthy container may not appear unhealthy within the Docker desktop which is why the previous "ls" command is so critical.

Check the logs. It will most likely be running the health check periodically and it will write the attempt to the logs. Here is an example of a failing CM health check:

GET /healthz/ready - 80 - ::1 Mozilla/5.0+(Windows+NT;+Windows+NT+10.0;+en-US)+WindowsPowerShell/5.1.17763.2268 - 500 0 0 35126

Notice that the health check is trying to visit /healthz/ready and is receiving a 500 status code. This means our application is experiencing a YSOD but we cannot see it in the Sitecore logs (because Sitecore cannot even start).

Next, issue this command in the shell to view the raw output:

curl http://127.0.0.1/healthz/ready

This very quickly showed me that we had a bad reference pushed and we cleaned it up.

A similar approach can be utilized on all container types. Each container may have a slightly different health check, but this approach gets directly to the root of the problem.