Scheduling Azure Batch Account
Can ZopNight schedule Azure Batch Account?
Batch schedules resize each pool to 0 dedicated nodes and return it to the saved size at start. Jobs and tasks submitted overnight simply queue, and the Batch account bills nothing by itself. Pools running an autoscale formula must have it disabled first, since a formula and a fixed resize cannot coexist.
How the stop works
| Field | Value |
|---|---|
| Behaviour | pools are scaled to 0 dedicated nodes on stop and restored to their saved size on start. |
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 queue makes this schedule forgiving
Batch decouples work from workers. Tasks submitted while a pool sits at 0 dedicated nodes do not fail; they wait in the job queue and begin executing when the morning resize brings nodes back. That property makes Batch one of the safest resources on the directory to schedule aggressively: an overnight submission is deferred, not lost, and no orchestrator upstream needs to be taught about the calendar.
Formulas and fixed resizes are mutually exclusive
A pool in autoscale mode is governed by its formula, and a fixed resize to zero cannot be applied over it. The schedule needs autoscale disabled on the pool to take effect. Where a formula already scales on pending tasks, check what it actually achieves overnight before replacing it. A well-written formula may already reach zero, making the calendar redundant; a conservative one that floors at 2 nodes is exactly what the schedule fixes.
What the 8am rebuild costs
Fresh nodes repeat their entire preparation: boot, start task, application package downloads, container image pulls. A pool whose start task installs heavyweight dependencies can take a long first act before any task runs. Sizing the start cron means adding that preparation time to the queue’s expected drain time, not just the VM allocation time.
Dedicated nodes only; spot is separate
The resize drives the dedicated node count; low-priority and spot nodes are tracked as their own target. Their pricing already discounts idle risk, and a pool leaning on spot capacity may owe more of its bill to the dedicated floor than the spot fleet, which is precisely the part the schedule removes.
Interrupted tasks follow pool policy
Tasks still running at the stop time are handled per the pool’s deallocation option. Requeue is typical, meaning the task reruns from the start on the next available node. Long tasks should checkpoint or be scheduled to finish before the window closes.