Is Qdrant Down?

If Prismix shows Qdrant as "Operational" but your collection operations are failing:

• Collection not found right after creation (replication lag) — in Qdrant Cloud's replicated clusters, a new collection may take a few seconds to propagate across all nodes. If you immediately query after creation, you may hit a replica that hasn't caught up yet. Add a short retry loop (3 attempts with 1s delay) after create_collection before inserting vectors.
• Upsert returning 413 Payload Too Large — Qdrant's REST API has a default request body limit of 32MB. Large batch upserts with many high-dimensional vectors (e.g., 10,000 × 1536-dim) easily exceed this. Split upserts into batches of 100–500 points per request, or use the gRPC API which has a higher streaming limit for batch imports.
• Cosine search returning wrong top-k (vector size mismatch) — Qdrant enforces that all vectors in a collection match the declared dimension. A common bug occurs when switching embedding models (e.g., from 768-dim to 1536-dim): old vectors in the collection have wrong dimensions, causing search to silently exclude them. Create a new collection and re-index when changing embedding models.
• Cloud cluster going to "degraded" state during rolling update — Qdrant Cloud applies rolling updates to cluster nodes. During the update, one node at a time goes offline, briefly reducing replication factor. If your cluster has replication factor 1, this causes a brief unavailability. Upgrade to replication factor 2 or more for production workloads to maintain availability during updates.
• API key permissions not propagating immediately — Qdrant Cloud API keys with restricted collection permissions may take up to 30 seconds to become active after creation. If a newly generated restricted key returns 403 immediately, wait 30 seconds and retry. This is a known eventual-consistency behavior in the Qdrant Cloud control plane.
• On-disk indexing blocking queries during HNSW index build — when you trigger optimizer_config to rebuild the HNSW index on a large collection, search queries continue to work but may run in brute-force mode (full scan) during the build, causing high latency. Schedule index rebuilds during low-traffic periods and monitor the optimizer status via GET /collections/{name}.