The Kubernetes Live Object Status feature is in early access, it is rolling out in Octopus Cloud now. This feature is coming to self-hosted customers in H2 2025.
Kubernetes Live Object Status shows the live status of your Kubernetes objects after they have been deployed. This allows you to monitor and safely troubleshoot your Kubernetes application directly from within Octopus Deploy.
Where it is available
Using Kubernetes Live Object Status requires the following:
- An Octopus Cloud instance
- A Kubernetes Agent target
- A project with a deployment process containing Kubernetes steps
- The kubectl script step is currently unsupported
How to use Live Status
Once you have the Kubernetes monitor enabled on your Kubernetes Agent, simply toggle the switch on the dashboard to show live status in place of the deployment status.
Octopus display individual status at an object level as well as summarized status for an Application.
Application status
| Label | Status Icon | Description |
|---|---|---|
| Progressing | Objects in your application are currently in a progressing state | |
| Healthy | The objects in your cluster match what was specified in the last deployment | |
| Unknown | We’re having trouble getting live status updates for this application | |
| Degraded | Your objects experienced errors after the deployment completed | |
| Out of Sync | The objects on your cluster no longer match what you last deployed | |
| Missing | Objects in your application are currently in a missing state | |
| Unavailable | Application live status is unavailable because your last deployment failed | |
| Waiting | Application live status will be available once the deployment completes |
Object status
| Label | Status Icon | Description |
|---|---|---|
| Progressing | Object is attempting to reach the desired state | |
| Healthy | Object is in sync and reporting that it is running as expected | |
| Unknown | We don’t have up-to-date information about the live status of this object | |
| Degraded | Object has run into a problem, check the logs or events to find out more | |
| Out of Sync | Object manifest is not the same as what was applied | |
| Missing | Object is missing from the cluster | |
| In Sync | Object manifest matches what was applied, but does not report any additional health status | |
| Suspended | Job is not currently running |
Take a look at our troubleshooting guide for details on why you may see some object statuses
Detailed object information
Each object reported back by the Kubernetes monitor can be selected to provide detailed information including events, logs and the manifest currently on the cluster
Events
Events are fetched on demand from the running object. Octopus reads and presents events in similar way to kubectl.
Logs
Logs are fetched on demand from the running object. We do not currently support tailing logs, but it is on the roadmap in the near future.
Manifest
The manifest shown here is the live manifest as reported by the cluster back to Octopus.
How it works
The Kubernetes Agent has a new component called the Kubernetes monitor which also runs inside the Kubernetes cluster. Read more about the Kubernetes monitor here.
During a deployment, Octopus will capture any applied Kubernetes manifests and send them to the monitor. The monitor uses these manifests to track the deployed objects in the cluster, keeping track of their synchronization and health.
User permissions
Viewing the data returned from the Kubernetes monitor from within Octopus requires DeploymentView permissions.
This data includes the resource and application status, as well as pod logs and events for objects being monitored. This may be a change in security posture that your team should carefully consider.
Secrets
Octopus sensitive variables
As always, we treat secret data as carefully as we possibly can.
Practically, this means that we redact any detected Octopus sensitive variables from:
- Manifests
- Logs
- Events
If we do not have all the required information to adequately redact something coming back from a Kubernetes cluster, we will opt to prevent the user from seeing this all together.
With that said, we highly recommend:
- Containing all sensitive information to Kubernetes secrets so they can be redacted at the source
- Never logging sensitive values in containers
The flexibility that Octopus variables provide mean that sensitive variables can turn up in unexpected ways and so our redaction can only be best effort.
Kubernetes secrets
The well defined structure of Kubernetes secrets allow us to confidently redact secret data.
To ensure that we never exfiltrate secret data that Octopus is not privy to, the Kubernetes monitor salts and hashes the secret data using sha256. By hashing secrets Octopus can tell you when something changed in your secret, but Octopus will never know what the secrets are unless you have populated them using Octopus sensitive variables.
Please be aware that outputting Kubernetes secrets into pod logs may result in them being sent un-redacted if they are not sourced from Octopus sensitive variables originally.
Known issues and limitations
Excluded steps
The desired object list is compiled from objects that were applied during the last deployment. If steps are excluded during a deployment, then live status will not be shown for objects that were applied in those steps.
Please avoid skipping steps that deploy Kubernetes objects.
Script steps are not supported
Objects modified by script steps directly are not monitored. Support for script steps is planned for a future release.
Runbooks are not supported
Objects modified by Runbooks are not monitored. Please deploy the objects via a Deployment if you want them to be monitored.
Help us continuously improve
Please let us know if you have any feedback about this page.
Page updated on Friday, March 28, 2025