We have a shell script that runs:

echo "Deploying components..."
sfdx force:source:push --forceoverwrite --targetusername $SFDC_USERNAME --loglevel trace

but this has recently started failing from our Jenkins Continuous Integration server that runs on Amazon EC2. The failure message tells us little:

 [exec] Deploying components...
 [exec] ────────────  ───────
 [exec]               Unknown

The same script run locally on a Mac on the same files works.

Is there a way to get more diagnostic information out of the SFDX tools? Or any thoughts on what the problem could be?


Same problem experienced in August 2017 with no good answer...


Running with the --json option didn't reveal anything more:

    "message":"Push failed.",
    "stack":"DeployFailed: Push failed.\n    at ALMError ...",

  • Could it be due to sfdx update of cli? What version of cli is installing on server ? can you source convert and run a deploy on dev org parallelly and see if any sfdc erros Mar 2, 2018 at 17:03
  • Hi Mohith, CLI is latest version of 6.5.0-a02d8a7ead in both places. Presume you know of no way to see more error detail?
    – Keith C
    Mar 2, 2018 at 17:05
  • Sometimes a pull first can resolve this error. Nov 15, 2018 at 1:02

3 Answers 3


The logs from the log-levels are written in


directory, did you check the contents in there on your Mac? Only errors are output to the terminal or command window from which you run the CLI, so you need to read in that file as documented here.

Also, you can open the scratch org, navigate to Deployment Status page to check any deployment errors you're encountering over there.

If there are many errors try using the --json flag to get the output in JSON format and write it in a CSV using JQ. We were not receiving any errors on the command line since we had around 25k deployment errors and the CLI, Deployment Status page and log file failed in providing the errors but using JQ to redirect and convert them to a CSV helped identifying them.

  • Thanks Abhishek; I don't see a .sfdx/sfdx.log file for either case. Will try the --json next.
    – Keith C
    Mar 2, 2018 at 17:11
  • @KeithC the .sfdx folder should be in your root directory and it's hidden, so make sure you can see hidden files. Mar 2, 2018 at 17:22
  • Yes I can see the .sfdx folder and other files in it.
    – Keith C
    Mar 2, 2018 at 17:24
  • 1
    FYI though, there is one .sfdx folder in the project directory, which contains scratch-org information for that particular project/directory. So that when you run sfdx force:org:list it shows you relevant orgs of that project, whereas another .sfdx folder in the root directory of your system to store global scratch org/dev hub information alongside logs from all your commands. Mar 3, 2018 at 4:46
  • 1
    In the end the sfdx.log was of no help and neither was the Deployment Status page. My colleague just had to back out pieces until the deployment works. Turned out to be 2 label files with the same name but different casing of the name that was causing the trouble.
    – Keith C
    Mar 5, 2018 at 11:43

I had the same error when trying to run the command

sfdx force:source:push
────────────  ───────

I found the error detail opening the Scratch Org, going to Setup, Deployment Status. This detail helped me to find the problem and correct the package and finally have a successful push.


I'm disappointed that the error message was a simple "Unknown". I didn't find any error under .sfdx folder.

For some reason the project ended up with 2 files with "same name" after renaming it.


Once I removed one of them, it worked properly. So, make sure there is no duplicated files with same name but different casing.

  • I've reported it to SFDX support team. Hopefully we will have a better error log soon. Mar 5, 2018 at 12:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .