Is it possible to print to helm install (or helm upgrade) output the logs of the deploying containers (logs that are available by kubectl logs command)?

  • I am currently working on a solution within our CI/CD system to do just that. it is what everyone really needs: To get the log output of a helmChart deployment when it fails. The challenge is to connect the dots. * extract the names from the helmchart to create the parameters for a kubectl -wait process to connnect to the pod created by the helmchart deployment. I keep you posted....
    – U.V.
    Commented Feb 11, 2023 at 22:53

4 Answers 4


Helm does not launch pods to deploy your workloads. Helm locally renders the charts into standard Kubernetes manifests, and applies them. There is no server side component to Helm (since Helm 3).

If you want to get logs from deployed pods, do so with standard kubectl logs commands against the deployed pods. If you want to view what Helm is doing, use the --debug parameter to Helm, which will output the manifests that Helm applied.


Short answer: no. You would most likely run helm commands from your own workstation.

For those logs to be available through "kubectl logs", you would have to start a Pod, executing your "helm install" command. Maybe using a Job. Although this also means having some ServiceAccount with enough privileges to install objects on behalf of Helm.

  • 1
    I need these logs to be available in CI/CD system. Developers should watch these logs without monitoring kubernetes pods manually.
    – Timur
    Commented Aug 4, 2022 at 0:06
  • If going through logs in Kibana (assuming you have EFK) or pod logs is not enough: in my CI, logs of the commands executed during a job are collected in a file, which is then pushed, alongside other reports into some s3 bucket.
    – SYN
    Commented Aug 4, 2022 at 19:27
  • As I understand, it is too hard to find necessary logs in Kibana if use EFK (we use ELK, and these logs aren't so convenient). I thought that the task is so simple. If the helm chart installation/upgrade is failed, I want to get logs of failed pods to stdout (or names of the failed pods).
    – Timur
    Commented Aug 7, 2022 at 4:42
  • EFK is quite simple, you would need one filter: the name of your pipelinerun. to find back its logs. Now, as I already suggested: if your end-users are not up to the task of filtering based on a single field in Kibana: then, you need to keep those logs somewhere else. Eg: s3. And you can probably shut down your EFK, being too complicated and all, .. it still consumes a lot usually.
    – SYN
    Commented Aug 7, 2022 at 7:01
  • the log search tools are just a super inefficient workarounds for this issue, sure its a solution but a very ugly one
    – U.V.
    Commented Feb 11, 2023 at 22:59

You can try a workaround by using the --wait flag with helm install or helm upgrade. This will cause the command to wait until the deployment is complete and all of the pods are ready, and then it will print the logs for the pods.

example: helm install my-release my-chart --wait

This will install the chart and then wait until the deployment is complete before printing the logs for the pods.

You can also specify a timeout for the --wait flag, like so:

helm install my-release my-chart --wait --timeout 600

This will wait up to 10 minutes for the deployment to complete before timing out and returning.

The catch is that the --wait flag only works if the chart being installed or upgraded has a Deployment or StatefulSet as the primary resource type. It will not work with other resource types such as DaemonSet or Job.


On a Linux system with background jobs and kubectl installed, there is a DIY way.

Make sure that your pods get one or more metadata labels that uniquely identify the pods with a Helm chart version that you're installing. Assuming it's the label chart and that it gets the value mychart-1.0.1, and that it's the only background job you're starting:

kubectl get pods --selector chart=mychart-1.0.1 --watch --output name > new_pods.csv &

helm install mychart --wait mychart-1.0.1.tgz

kill %1

while read pod || [ -n "$pod" ]; do
  kubectl logs $pod
done < <(sort -u new_pods.csv)

kubectl get pods ... --watch ... & starts a background job that continuously outputs pod names on pod events that belong to your chart version install.

helm install --wait installs the chart and blocks.

kill %1 kills the background pod watch. I'm assuming here that that was the only background job you started. If you have more, you need to add a bit more complexity to find out the job id of the process.

while read pod ... loops through the unique-ified file that the pod watch wrote to. unique-ified, because the pod watch printed the same name multiple times for every state change per pod, and you wouldn't want duplicate log prints of the same pod.

New contributor
K.Sy is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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