> Explore Qdrant's agent skills catalog at https://skills.qdrant.tech/
> Search the documentation at https://skills.qdrant.tech/search?query=your+query+here
> Use this file for an index of the main pages: https://qdrant.tech/llms.txt


# Cluster Alerts

The account owner receives these alerts by email. Each row gives the condition that triggers the alert, what it means for your cluster, and how to resolve it. For the metrics behind them, see [Monitor Clusters](https://qdrant.tech/documentation/cloud/cluster-monitoring/index.md). To read firing and resolved alerts in your own automation, run `qcloud cluster alert list <CLUSTER_ID>` in the [Cloud CLI](https://qdrant.tech/documentation/cloud-cli/index.md) or call the `ListClusterAlerts` method of the [Cloud API](https://qdrant.tech/documentation/cloud-api/index.md).

## Capacity

| Alert | Triggers when | What it means | How to resolve |
|---|---|---|---|
| Memory Overutilized | Memory use is above 80% of the allocation for more than 5 minutes | If usage keeps growing past the allocation, the cluster fails from resource pressure and you see disruption | [Scale vertically](https://qdrant.tech/documentation/cloud/cluster-scaling/index.md#vertical-scaling) for more capacity per node, [scale horizontally](https://qdrant.tech/documentation/cloud/cluster-scaling/index.md#horizontal-scaling) to spread the load, or reduce memory with [quantization](https://qdrant.tech/documentation/manage-data/quantization/index.md) or the `cold` [memory tier](https://qdrant.tech/documentation/ops-configuration/memory-tiers/index.md) |
| Disk Space Overutilized | Disk use is above 80% of the allocation for more than 5 minutes | Same as memory: the cluster fails from resource pressure if usage keeps growing | [Scale vertically](https://qdrant.tech/documentation/cloud/cluster-scaling/index.md#vertical-scaling) for more disk per node, or [scale horizontally](https://qdrant.tech/documentation/cloud/cluster-scaling/index.md#horizontal-scaling) to spread the data. See [Capacity Planning](https://qdrant.tech/documentation/capacity-planning/index.md#scaling-disk-space-in-qdrant-cloud) |
| A Node Ran Out of Memory | A node tried to allocate more RAM than available and the operating system stopped the Qdrant process | A highly available cluster may avoid total downtime, but it is unstable. Without high availability, expect disruption until the cluster is scaled up | Scale vertically or horizontally, reduce memory with [quantization](https://qdrant.tech/documentation/manage-data/quantization/index.md), and make the cluster [highly available](https://qdrant.tech/documentation/cloud/production-checklist/index.md#availability) |
| A Node Ran Out of Disk Space | Disk use on a node is above 99% | The node cannot store new vectors | [Scale vertically](https://qdrant.tech/documentation/cloud/cluster-scaling/index.md#vertical-scaling) for more disk, or [scale horizontally](https://qdrant.tech/documentation/cloud/cluster-scaling/index.md#horizontal-scaling) and [reshard](https://qdrant.tech/documentation/cloud/cluster-scaling/index.md#resharding) if there are too few shards to use the new nodes. See [Capacity Planning](https://qdrant.tech/documentation/capacity-planning/index.md#scaling-disk-space-in-qdrant-cloud) |
| One or More Nodes Are in Recovery Mode | A node failed to start, usually because it ran out of memory, and restarted in [recovery mode](https://qdrant.tech/documentation/ops-configuration/administration/index.md#recovery-mode) | The node loads only collection metadata, so the only collection operation available is deleting a collection. The node does not serve search or writes | Scale the cluster [vertically](https://qdrant.tech/documentation/cloud/cluster-scaling/index.md#vertical-scaling) for more memory, or reduce memory with [quantization](https://qdrant.tech/documentation/manage-data/quantization/index.md). Delete a collection only on a proof-of-concept or toy cluster where the data does not matter |
| A Node is CPU Throttled | CPU throttling is above 25% for 30 minutes | CPU is saturated, so searches and writes respond much slower. The usual cause is a heavy write load while indexes are created or updated, or heavy search load with inefficient queries | Write in batches when search traffic is low, run fewer parallel writes, [index your data](https://qdrant.tech/documentation/manage-data/indexing/index.md), simplify heavy [hybrid and multi-stage queries](https://qdrant.tech/documentation/search/hybrid-queries/index.md), [tune the optimizers](https://qdrant.tech/documentation/ops-optimization/optimizer/index.md), or scale the cluster |

Deleting data is a last resort for these alerts. Use it only on a proof-of-concept or toy cluster where the data does not matter. On any other cluster, scale or reconfigure instead.

## Availability and Health

| Alert | Triggers when | What it means | How to resolve |
|---|---|---|---|
| Cluster is Unhealthy | One or more nodes have been unhealthy for more than 5 minutes | There is a serious issue that needs attention | Check the other alerts first. Then look at recent client code or configuration changes, and at increases in search or write requests |
| Cluster Has Too Many Collections | The cluster has more than 500 collections | Many collections add significant resource overhead and, left alone, degrade resilience and can cause outages | Use one collection with [payload-based partitioning](https://qdrant.tech/documentation/manage-data/multitenancy/index.md) in place of one collection per tenant. You can also split collections across clusters with the [Migration CLI](https://qdrant.tech/documentation/migrate-to-qdrant/index.md) |

## Versions and Keys

| Alert | Triggers when | What it means | How to resolve |
|---|---|---|---|
| Cluster Version is Not Covered by SLA | The cluster runs a version older than the latest and previous 3 minor versions | Support requests against the cluster are not covered by the SLA | [Update the cluster](https://qdrant.tech/documentation/cloud/cluster-upgrades/index.md) |
| Database API Key is About to Expire | A Database API key expires within 7 days | Requests with an expired key fail, which can break queries and applications | Create a new [Database API key](https://qdrant.tech/documentation/cloud/authentication/index.md) and update your application |

## Uneven Load

| Alert | Triggers when | What it means | How to resolve |
|---|---|---|---|
| Node CPU Usage is Not Distributed Equally | CPU usage differs across nodes | Some nodes carry more load than the rest, which slows search and can cause node failures. Uneven data distribution is the usual cause | Reshard and rebalance shards. See [Shard Rebalancing](https://qdrant.tech/documentation/cloud/configure-cluster/index.md#shard-rebalancing) |
| Node RAM or Disk Space Usage is Not Distributed Equally | RAM or disk usage differs across nodes | Same as CPU: hotspots slow search and can cause node failures | [Reshard](https://qdrant.tech/documentation/cloud/cluster-scaling/index.md#resharding) to split a collection across more nodes, and let [rebalancing](https://qdrant.tech/documentation/cloud/configure-cluster/index.md#shard-rebalancing) even out the shards |

Qdrant Cloud rebalances shards in the background by default. It balances the total shard count and size per node across all collections combined, so a single collection can look uneven while the cluster as a whole is balanced.