Azure Data Explorer (Kusto) Cluster
Does ZopNight manage Azure Data Explorer (Kusto) Cluster?
Azure Data Explorer clusters run always-on compute that bills continuously, and the Kusto stop operation halts that compute while storage continues. ZopNight stops dev and staging clusters off-hours (the stop and start operations only apply from the Running state) using 60 days of query and ingestion metrics to confirm idleness.
Rules that fire on Azure Data Explorer (Kusto) Cluster
No active rule family targets Azure Data Explorer (Kusto) Cluster today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | stopped and started via the Kusto cluster stop/start operations, but only when the cluster is in the Running state. |
Azure Data Explorer is a fast analytics engine for log and telemetry data, running on always-on compute clusters. Dev and staging Kusto clusters left running around the clock are high-value scheduling targets.
Always-on Kusto compute and its meter
A Data Explorer cluster bills for its compute SKU and instance count for every hour it is running, whether it is ingesting millions of events or none. The engine’s hot cache lives on that compute, which is precisely why the platform keeps it on, and why an idle cluster is expensive idle. Storage for retained data is metered separately and persists through a stop, so stopping trades query availability for the elimination of the compute line.
Stopping a cluster from the Running state
The Kusto stop and start operations are state-gated: they succeed only when the cluster is in the Running state, and ZopNight respects that gate rather than colliding with a cluster mid-transition. While stopped, ingestion and queries are unavailable. That is a real outage for anything consuming the cluster, which is why the schedule pattern fits development and staging clusters whose consumers keep office hours, not production telemetry pipelines.
Ingestion-aware idle detection
Discovered via Azure Resource Graph with SKU and state. Azure Monitor metrics (60-day lookback) show query and ingestion activity, Cost Management billing attributes spend, and schedules stop clusters off-hours. ML auto-tagging covers this type. Having both query and ingestion signals matters for Kusto specifically: a cluster nobody queries may still be receiving a live event stream, and stopping it would silently drop data.
Kusto clusters that burn money
Watch for engineering sandboxes sized like production because the SKU was copied from a template; clusters retained purely as historical archives, paying always-on compute for data that a stopped cluster would hold just as well; and follower or test clusters spun up for an investigation and never revisited.
Cluster status on the Data Explorer blade
Azure portal → Azure Data Explorer Clusters shows every cluster with its State column reading Running or Stopped, plus Stop and Start controls on each cluster’s Overview page, the same operations a ZopNight schedule drives.