# Valkey Admin 1.0 unifies cluster inspection and troubleshooting > Valkey Admin 1.0 adds topology, key browsing and command logs, with server-version prerequisites and web-interface authentication to plan. Canonical URL: https://www.devobs.io/news/news-valkey-admin-10-cluster-diagnostics/ By: Jonah Reed Published: 2026-09-06T11:58:54.645Z Updated: 2026-09-06T11:58:54.645Z Event date: 2026-05-12 Section: Data Valkey released Admin 1.0 on May 12, bringing cluster topology, metrics, key inspection, command execution, hot-key detection and aggregated command logs into one tool. The [announcement](https://valkey.io/blog/introducing-valkey-admin-1-0-visual-cluster-management-for-valkey/) offers macOS and Linux desktop applications plus containerized web deployment. ## Diagnosis depends on server capabilities The tool combines a cluster view with inspection of individual keys and command activity. Its command-log capability requires Valkey 8.1 or later. The lower-overhead hot-slot approach has its own prerequisites, including cluster mode, slot statistics and an LFU eviction policy. Where that approach is unavailable, the tool can use sampled `MONITOR` activity, which carries additional overhead. Our analysis is that the detection method should be chosen and rehearsed before an incident. An operator needs to know whether opening a troubleshooting view changes the load on an already saturated service. ## Access control is part of deployment The announcement explicitly states that the web interface has no built-in authentication and should sit behind an authentication layer. That matters because this is an administrative surface with key-editing and command-execution capabilities, not merely a public metrics dashboard. Start with a restricted non-production cluster and exercise the intended operator workflow. Check which accounts can inspect values, change data and issue commands, and ensure the access layer applies to the whole interface. For a production trial, compare an Admin finding with the team's existing metrics and command-line diagnosis. Record which signals come from primaries and which describe replica status. A useful outcome is a shorter, repeatable path from a latency spike to its responsible shard, with the diagnostic overhead understood. ## Source references -