Overview of logging options in Bluemix

Share this post:

As an developer or operations person knows, logs are crucial to understanding how their application is being used. Logs are important for understanding when errors happen in an application as well. If you do not have the logs for an application you, can not go back in time to figure out what went wrong in your application. Additionally logs are important for security and audit reasons as well and need to be stored for those types of situations.

Bluemix has three different types of logging mechanisms built in:

  • Bluemix UI
  • Cloud Foundry Command Line Interface (CLI)
  • External logging

I review the options in the video below:

Watch the video (

Below I will cover the points in the video with additional details.

Logging option #1: Bluemix UI

In the Bluemix UI, you can get your logs with the following steps:

  • Login to Bluemix
  • Click Dashboard
  • Click on your application
  • Click on Files and Logs:
    files and logs
  • Expand the logs folder:

You will be given some of the logs for your application here. Note the logs you receive here will vary between the various runtime languages.


  • Really easy to get to in a web browser


  • Does not show all the logs
  • Logs vary between languages
  • Logs are not aggregated together if you have multiple instances of your app
  • Logs are not persisted between app crashes and deployments.

Logging option #2: Cloud Foundry CLI

At first glance, the Cloud Foundry CLI appears to give you almost everything you need except retention, so let’s jump into how it works. As a reminder, the Cloud Foundry CLI is the command line interface for Cloud Foundry; Cloud Foundry is what Bluemix is built and runs on. To get started with the CLI, do the following:

  • Click on your app in the dashboard in the Bluemix UI
  • Click on Start Coding
  • Follow the instructions on the screen:
    cf cli

Once you have the CLI setup, you can get logs from your app. Use the following command:

cf logs myappname

Replace myappname with the name of your application. The above command will connect to Bluemix and give you real-time aggregated logs from all of the instances of the app. Note these logs do not go into the past.

However, you can get a glimpse into your app’s past logging with the CLI. But wait, didn’t I just say you can not get logs in the past? Well, yeah, but with a caveat. You can get logs into the past for recent log entries with the CLI. This is super helpful if you app fails to start or you just need to look at something that recently happened. To do this use the following:

cf logs myappname --recent

The --recent argument tells the CLI to grab logs that haven’t yet been overwritten. I use this a lot for debugging apps that failed to start.


  • Shows all the logs for your app (standard out and standard error)
  • Logs are aggregated together if you have multiple instances of your app


  • Logs require a little more work than the UI to get
  • Logs are not persisted between app crashes and deployments
  • Logs do not have a full history of your app.

Logging option #3: External Logging

There is one last option and I saved the best one for last—Cloud Foundry allows you to send logs in real-time to a third party log aggregator such as Papertrail, Splunk, Sumologic, any syslog host, any syslog-tls host, or any HTTPS POST endpoint.

Let me emphasize that again: You can write your own logging endpoint and Bluemix will send you the logs for your app.

One day I had some spare time and wrote a little Node.js app that ran in Bluemix that just had an HTTPS POST endpoint that accepted logs for my applications and stored them in a Cloudant database. I ended up writing a view that allowed me to do full text searching on logs. Pretty slick.

The power of this option here is choice. You can basically send your logs anywhere you want. Additionally, by sending your logs somewhere to be stored, you gain an advantage the two options lacked, namely full retention. So let’s go through how this works.

To setup an external logging provider, you need to have the Cloud Foundry CLI installed. You will need to get the logging endpoint for your logging provider (for details, see the References section at the end of this post); once you have this, you can setup logging.

For example, here’s the commands to enable logging to Papertrail:

cf cups my-logs -l syslog://<br />cf bind-service myappname my-logs<br />cf restage myappname

You will need to replace myappname with the name of your application and additionally replace PORT with the correct port for Papertrail. So let’s walk through what that is doing:

  • cf cups my-logs -l syslog:// creates a logging endpoint
  • cf bind-service myappname my-logs connects the logging service to the app
  • cf restage myappname restarts the app and attaches the logging service to the real-time stream of logs.

Alternatively, you can log to syslog/syslog-tls using the following command:

cf cups my-logs -l syslog://HOST:PORT


cf cups my-logs -l syslog-tls://HOST:PORT

Replace HOST and PORT with your information. Note, if your are using syslog-tls you can not use self-signed certificates—the certificate must be trusted by a certificate authority.

Finally, below is the command to specify HTTPS POST logging:

cf cups my-logs -l https://HOST:PORT

Replace HOST and PORT with your values.


  • Shows all the logs for your app (standard out and standard error)
  • Logs are aggregated together if you have multiple instances of your app
  • Logs have a full history of your app
  • Logs are persisted between app crashes and deployments


  • Setup requires a little more work than the UI.


I personally use a combination of the Cloud Foundry CLI and external logging. I like using the --recent argument with the CLI when I am working on a new app and it fails to start. Then I like streaming the logs with the CLI when I am doing development or testing. Then once the app moves to production, I like using an external logging provider to save all my logs.

I would love to hear your feedback and any suggestions you have, please reach out to me on Twitter @jsloyer.


IBM Cloud Kubernetes Service - Core Dev Lead

More stories
May 1, 2019

Two Tutorials: Plan, Create, and Update Deployment Environments with Terraform

Multiple environments are pretty common in a project when building a solution. They support the different phases of the development cycle and the slight differences between the environments, like capacity, networking, credentials, and log verbosity. These two tutorials will show you how to manage the environments with Terraform.

Continue reading

April 29, 2019

Transforming Customer Experiences with AI Services (Part 1)

This is an experience from a recent customer engagement on transcribing customer conversations using IBM Watson AI services.

Continue reading

April 26, 2019

Analyze Logs and Monitor the Health of a Kubernetes Application with LogDNA and Sysdig

This post is an excerpt from a tutorial that shows how the IBM Log Analysis with LogDNA service can be used to configure and access logs of a Kubernetes application that is deployed on IBM Cloud.

Continue reading