I have installed Sitecore 10 on Docker on my local machine.

Today I am trying to start using following command error message coming on powershell:

Command: docker-compose.exe up --detach


ERROR: for traefik  Container "b54284cd154a" is unhealthy.

ERROR: for xdbautomationworker  Container "c1a32b355624" is unhealthy.

ERROR: for xdbsearchworker  Container "c1a32b355624" is unhealthy.

ERROR: for cortexprocessingworker  Container "c1a32b355624" is unhealthy.
ERROR: Encountered errors while bringing up the project.

Checked the following things:

  1. IIS is stopped
  2. 8984 port is free
  3. Powershell is in Adiminstrator mode
  4. Stopped, removed the container and executed the command docker-compose.exe up --detach multiple times but no luck.

enter image description here

Can anyone help me here?

Thanks in advance.

4 Answers 4


I faced this issue too during installation. Try the below steps:

  1. Run docker-compose stop on Powershell.
  2. Run docker-compose down on Powershell.
  3. Now run iisreset /stop on Powershell to make sure that the required ports are free.
  4. Now run docker-compose up -d on Powershell.

Hoping this solves your issue.


1. VPN turned on

Turned on VPN can also cause problem when starting up docker. Try to turn off your VPN and recheck, although I don't know the exact reason why VPN is a problem.

2. SQL password

For me changing the SQL_SA_PASSWORD in the .env solved the problem. Important to run the clean.ps1 to clean up the already generated database files. Then you can try to rerun the up.ps1 in case if you are using the Getting Started template.

Related documentation: https://containers.doc.sitecore.com/docs/troubleshooting

To resolve, change the SQL password in SQL_SA_PASSWORD to fit the default SQL Server policy. After changing the password in the .env file, remember to clear the mounted SQL data folder after running docker-compose down. You can manually delete its contents, or use a clean script (see the clean.ps1 example in the the Docker Examples repository).

  • For me, the environment was up and running. If I change the password in .env file, will it sync with the existing one?
    – Jitendra
    Oct 26, 2020 at 14:03
  • @Jitendra you are right, you also need to rerun docker-compose build and then rerun docker-compose up --detach Oct 26, 2020 at 14:38
  • @Jitendra it could be also related to VPN connection, try to turn off your VPN while running .\up.ps1 Nov 3, 2020 at 8:10
  • 1
    I have the same issue and I also think that enabled VPN might become a root cause of this failure. Unfortunately, I'm unable to turn off VPN due to company policies. I wonder did anybody dig deeper and figure out why exactly VPN might become the root cause of this problem? Feb 3, 2021 at 23:13
  • 1
    I solved the issue by turning off VPN connection. Jan 5 at 13:27

I tried all above steps but issue did not resolve. Best way to understand what actually is causing issue by checking logs.

Open Visual Studio -> View -> Other Windows --> Containers

Check logs for those specific container which are failing would help to resolve issue.

For me the path of licence file was incorrect in "docker-compose.override.yml" file. After correcting the path it worked.


The true answer is to check why the health check is failing. This is mostly straightforward...

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. Note: An unhealthy container may not appear unhealthy within 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:


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.