Scheduling Azure Data Explorer (Kusto) Cluster
Can ZopNight schedule Azure Data Explorer (Kusto) Cluster?
Kusto cluster schedules issue stop only when the cluster reports Running, and anything else is soft-skipped. While stopped, ingestion halts, so Event Hub sources must be resumed within their retention window or events age out; starts take well over 10 minutes, and the hot cache rebuilds from scratch afterward.
How the stop works
| Field | Value |
|---|---|
| Behaviour | stopped and started via the Kusto cluster stop/start operations, but only when the cluster is in the Running state. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
The state gate comes first
Stop and start are only attempted against a cluster in the Running state. Mid-scale, updating or already-stopped clusters are skipped rather than forced, so the schedule cannot corrupt an in-progress operation, but a skipped stop also means a night at full price. Watch the first week’s runs to confirm the cluster is actually cycling rather than perpetually busy at the stop hour.
Ingestion stops, retention clocks keep running
A stopped cluster ingests nothing. Data sitting in upstream buffers waits, and each source has its own patience: Event Hubs hold events only for their configured retention, typically 1-7 days. An overnight window is comfortably inside that; a stop that stretches across a long weekend plus a holiday starts flirting with the limit, and events that age out are gone without an error on the Kusto side. Confirm the source retention exceeds the longest scheduled gap by a margin.
Cold cache, slow first queries
Kusto’s interactive speed comes from the hot cache on local SSD, and a started cluster begins with it empty. Queries fall back to storage until the caching policy repopulates, so first-hour dashboards run visibly slower than their afternoon selves. Warm-up queries after the start cron, touching the hot tables in rough priority order, turn a rough first hour into a rough first few minutes.
Starts are measured in tens of minutes
Bringing a Kusto cluster up is heavyweight: expect well over 10 minutes from start to queryable, longer for large clusters. The start cron belongs an hour before the first analyst, not fifteen minutes.
What stays on the bill
Compute engine and data-management nodes stop charging. The storage layer underneath, where all ingested data lives, bills continuously, as do any follower-related resources outside the cluster. The saving is the compute line, which for interactive analytics clusters is fortunately most of the total.