# Troubleshooting overview

> Start here to triage a CubeCOS issue before moving to instance, network, or storage specific troubleshooting steps.

Use this page to triage a CubeCOS issue before you dig into a specific area. Start with the cluster-wide health checks below, then move to the guide for the affected workload.

## Before you begin {#before-you-begin}

Some checks in the following sections require SSH access to the CubeCOS cluster virtual IP (VIP) as the `admin` user, or access to the OpenStack CLI on a controller node. Ask your platform administrator for access if you don't have it.

## Check the overall cluster health {#check-the-overall-cluster-health}

Start with a cluster-wide health check. Many instance, network, and storage problems trace back to a service reported here.

- **Web UI**: Review the health indicator panel in the dashboard. If it reports an error, click **Repair** to run an automated recovery action.
- **CLI**: Log in to the VIP with SSH, then run `cluster check_repair`.

  ```bash title="Check cluster service health"
  ssh admin@<cluster-vip>
  ```

  ```bash title="Run a service health check"
  controller> cluster check_repair
  ```

  Each row lists a service (for example, `Network`, `Compute`, `Storage`) and a status of `ok` or `FIXING`. A `FIXING` row identifies the failing component in brackets, such as `neutron(3)` for a network issue or `nova(8)` for a compute issue.

  For the full command output and an explanation of each service, see [Monitor and repair CubeCOS services using the web UI or CLI](../maintenance/cluster/check-repair).

## Review logs and events {#review-logs-and-events}

If the cluster health check doesn't explain the issue, review the logs for the affected resource.

- **Instance action logs**: Navigate to **Compute > Instances**, select the instance, open the **Action Logs** tab, and click **Analyze** on the event you want to investigate.
- **Cluster-wide log search**: Navigate to `http://<cluster-vip>:5601/opensearch-dashboards/app/data-explorer/discover` to query logs across all CubeCOS services.

For more information, see [Log analysis in CubeCOS](../logs/analysis).

## Check for existing alerts {#check-for-existing-alerts}

Navigate to **Events > Triggers** to see whether an existing trigger already caught the issue, and to review any notifications it sent. For more information, see [Manage triggers](../logs/triggers).