Monitor workloads & read logs

Check health, events and application logs; define useful alerts and the limits of collected metrics.

GuideTechnical reference · not required for Cloud UIReading time · approx.8 minutesUpdated22 October 2026

Availability of this guideEnterprise reference

For Enterprise Self-Hosted or a separately agreed technical evaluation. Not a Cloud customer procedure.

Before you start

You have a provided pilot cluster, a trusted kubeconfig, kubectl and access to an agreed namespace. Set KUBECONFIG, CP_CONTEXT and CP_NAMESPACE using the access guide before running the commands. The examples use a POSIX shell and a single access file. Grouped blocks stop at missing settings without closing your terminal; they do not provision infrastructure or grant permissions. Connect to your cluster →

Confirm your permission to read events and application logs. Dashboards, metric retention, log aggregation and operator alerts are only included when qualified and agreed for the pilot.

Start with application health

A small workload health check

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" get deployment/cloud-demo
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" get pods -l app=cloud-demo
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" get events --field-selector type=Warning --sort-by=.metadata.creationTimestamp
)

Compare desired/available replicas, readiness and restart counts. A running container can still be unready or serving errors. Check the application's own response and a representative user action as a separate signal. Events are diagnostic observations with limited retention, not an incident archive.

Read bounded logs

Recent application logs · review locally

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" logs -l app=cloud-demo --all-containers=true --prefix=true --since=15m --tail=100 --limit-bytes=32768
)

Select the relevant container and time window. For a restarted container, use the previous instance when it is still available:

Previous instance · replace the Pod name

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
export CP_POD="YOUR_POD_NAME"
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" logs "$CP_POD" -c app --previous --tail=100 --limit-bytes=32768
)

Use metrics when the API is available

Optional resource metrics

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" top pods --containers
)

This requires a working Metrics API and your permission to read it. “Metrics API not available” is not proof of zero usage or a workload failure. Ask whether metrics are included and qualified. A short top sample is not a historical sizing analysis; combine agreed retained metrics with load tests and application latency/error measurements.

Plan compute & storage →

Define alerts that someone owns

Signal	Action to agree
User request failure / latency	Application owner checks dependency, release and error rate against an agreed threshold.
Replica loss / repeated restarts	Inspect workload health, then escalate infrastructure evidence through the pilot channel.
Storage growth / backup age	Confirm threshold, time to capacity and whether the protection service is actually included.
Certificate expiry	Identify the renewal owner and verify the replacement before expiry.

Agree the recipient, coverage hours, escalation route and response expectation for each alert. A configured dashboard does not imply 24/7 staffed incident response.

Get useful support quickly →

Technical references

These Kubernetes references describe technical behavior. Your pilot agreement defines the capabilities confirmed for your cluster.

Use this guide within your agreed pilot scope. Kubernetes examples are not evidence of a generally available Cloud capability.