On this page
Monitor and troubleshoot in the browser
Read cluster, node and application evidence, isolate common failure states and escalate with a safe, redacted operation record.
These steps describe the intended customer path. Use the interface only after personal access and written confirmation of this capability in your pilot scope.
Before you start
Use an authenticated workspace with the cluster scope named in your pilot. Confirm which monitoring, logs, retention and support hours are included. The dashboard exposes bounded status, activity, operation, workload, event and log views; it is not an unrestricted shell or a promise of 24/7 staffed response.
1. Start with observed status
| View | Read | Do not infer |
|---|---|---|
| Cluster | Current state, last observation, version and affected scope. | Green page means every application path works. |
| Nodes | Role, readiness, capacity notice and operation history. | Node count alone proves high availability. |
| Application | Revision, rollout, readiness, recent events and bounded logs. | Running container proves business correctness. |
2. Triage a failure in the browser
- 01
Open the affected resource
Follow the link from Overview or Activity and verify organization, workspace, cluster, namespace and application.
- 02
Read the bounded evidence
Check current status, timestamp, revision, event reason, readiness result, restart indicator and the selected log window. The page should redact secrets and cap the amount of returned data.
- 03
Classify before acting
Separate image or configuration error, capacity/scheduling issue, dependency failure, network/endpoint issue, and platform operation failure. Choose only the action offered for your role.
- 04
Record the operation
Save operation ID, time range, impact, last change and redacted evidence. Do not paste tokens, kubeconfigs, secrets or full request bodies into support.
3. Use safe browser actions
| Observed state | Safe next step |
|---|---|
| Pending / unscheduled | Review resource requests, node capacity and events; request capacity if the pilot allows it. |
| Image or probe failure | Open the revision and release validation, correct the approved input and use the visible rollback path. |
| Degraded node | Do not remove it blindly; open the operation or request managed replacement with maintenance context. |
| Unknown / delayed | Wait for the operation or escalate with its ID; do not repeat a chargeable mutation. |
4. Escalate with a useful report
- ✓Subject, organization/workspace/cluster/application and start time with timezone.
- ✓User impact, expected behavior, observed behavior and the last change.
- ✓Operation ID, revision, affected namespace and the exact redacted error.
- ✓Checks already performed and a safe recovery decision; never include credentials.
Operate from the Cloud workspace → · Get useful support quickly →
Use this guide within your agreed pilot scope. Kubernetes examples are not evidence of a generally available Cloud capability.