Scheduling

Non-production cloud accounts cost as much as production at 3am and on weekends, when nobody is using them. A schedule powers them down outside business hours using each cloud’s native stop, start, or pause, and brings them back before the team starts work. It is the single largest savings opportunity in most non-prod estates: customers running ZopNight scheduling at scale typically cut non-prod spend by roughly a quarter. The exact figure varies by estate.

Automate → Schedules: each schedule shows its next run, daily on/off pattern, estimated saving, and what it’s attached to.

Before you start

• A role that can manage schedules (the schedule policies; the built-in Editor and Admin roles have them).
• Cloud accounts at the Read + Write permission level for the resources you want stopped and started. On a read-only account you can attach a schedule, but ZopNight never starts or stops the resource. See Read-only vs read + write.
• The resources discovered in your inventory. See Resources.

How it works

A schedule is a name, a timezone, and one or more cron expressions for its start and stop times. You attach it to individual resources or to resource groups, and changes to the schedule propagate to every attached resource and group member. The YAML below shows that underlying conceptual model, not a file you author by hand:

name: dev-night-shift
timezone: Asia/Kolkata
start: "0 9 * * 1-5"     # 9 AM weekdays
stop:  "0 20 * * 1-5"    # 8 PM weekdays
attached:
  resource_groups: [dev-stack]
  resources: [ci-runner-01]

Each schedule carries its own timezone, so the same organisation can run an India schedule (Asia/Kolkata) alongside a US-East schedule (America/New_York) without manual UTC offsets.

At each trigger, ZopNight calls the provider’s own API for the resource type (for example, Azure deallocate rather than stop, or node-pool scaling for EKS). For one-off exceptions to a schedule (keeping a resource up or down for a bounded window), set an override rather than editing the schedule. See Overrides.

Sequenced execution

Real workloads have order constraints: the app server can’t start before the database, and the database can’t start before its storage is attached. ZopNight’s scheduler runs group start / stop in an order you configure at the resource-group level.

You can also set a per-resource delay (in seconds) so a database start gets time to accept connections before the app server start fires. Sequencing matters most for Start. Stop is usually fine in reverse order or in parallel. See Resource groups.

Create a schedule

1. Open Automate → Schedules → Create Schedule

   Give the schedule a name, an optional description, and a timezone (IANA format, for example Europe/London).

2. Set the start and stop times

   Define when resources start and when they stop. Each schedule can hold several start and stop times, for example weekday hours plus a weekend stop.

3. Attach resources or groups

   Attach individual resources, resource groups, or both. Attaching a group applies the schedule to every current and future member.

4. Check the schedule card

   The card on Automate → Schedules shows the next run, the 24-hour on/off bar, the estimated saving, and the attached resource and group counts.

To take a resource off a schedule, detach it (one at a time or in bulk). To change the policy for everything attached, edit the schedule.

Production-safe overrides

Two mechanisms keep production resources from being stopped accidentally:

1. Overrides: set an override on a specific resource or resource group to Keep Running (block any scheduled stop) or Force Stop (block any scheduled start) for a defined time window. Overrides are time-bounded; a maximum duration policy prevents indefinite overrides. See Overrides for the full behaviour.
2. K8s system namespaces: at the executor, namespace-level Stop refuses to act on kube-*, zopnight-*, istio-*, helm-*, default, and kube-node-lease before any kube call fires.

Creating or cancelling an override is captured in the audit log with actor, timestamp, and reason. Channels subscribed to override events are told when an override is set, cleared, or expires.

Smart Tags integration

Non-prod estates are often under-tagged, which makes it hard to scope a schedule to them. ZopNight’s Smart Tags derive a consistent virtual tag from a policy you define (based on a resource’s provider, region, type, instance type, or name), so you can group and filter resources even when their cloud tags are inconsistent. Smart Tags stay inside ZopNight unless you explicitly apply them to the cloud, and each derived value stays pending until you accept it. See Smart Tags.

What gets scheduled

ZopNight schedules 30+ resource types across the three clouds using each cloud’s native stop / start / pause primitive. The core set covers EC2, RDS, EKS, GCE, GKE, Cloud SQL, Azure VMs, AKS, Databricks, ECS (service scaling), ASG (capacity scaling), and Lambda (concurrency throttling).

It also covers:

ZopNight also supports namespace-level lifecycle for EKS / GKE / AKS. Stop scales every Deployment and StatefulSet in the namespace to zero and suspends every CronJob (saving prior replicas, HPA, and PDB); Start restores them. System namespaces (kube-*, zopnight-*, istio-*, helm-*, default, kube-node-lease) are rejected at the executor before any kube call.

Troubleshooting

Next steps