Scheduling

Why scheduling

Non-production cloud accounts spend the same money as production at 3am and on weekends; and nobody is using them. A schedule that powers them down outside business hours is the single largest savings opportunity in most non-prod estates. Customers running ZopNight scheduling at scale commonly see a meaningful drop in non-prod spend (roughly a quarter is typical, though the exact figure varies by estate).

The Schedules page; each schedule shows its weekly on/off pattern, estimated savings, and attached resources.

What gets scheduled

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

Additional resource types were added on top:

• AWS Kubernetes workloads: EKS Deployments (scale replicas), EKS StatefulSets (scale replicas), EKS CronJobs (suspend / resume).
• GCP Kubernetes workloads: GKE Deployments, GKE StatefulSets, GKE CronJobs.
• Databricks (AWS / Azure / GCP): Workspace, Clusters, Instance Pools, SQL Warehouses. See Databricks.
• AWS additional: SageMaker Notebooks, ElastiCache, Beanstalk Environments, EMR Serverless, App Runner (pause/resume).
• Azure additional: MySQL Flexible, PostgreSQL Flexible, Data Explorer, Synapse SQL Pools, SQL VMs, SSIS Integration Runtimes, ML Compute.

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.

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 a configurable order, configured at the resource-group level.

You can also set a per-resource delay (in minutes) 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.

Defining a schedule

You create and edit schedules in the ZopNight UI on the Schedules page. Under the hood a schedule is a cron expression with a timezone and an action; the YAML below shows that underlying conceptual model, not a file you author by hand:

name: dev-night-shift
timezone: Asia/Kolkata
scope:
  account: "123456789012"
  filters:
    - environment: dev
    - tag:auto-stop: "true"
stop:
  cron: "0 20 * * MON-FRI"      # 8 PM weekdays
start:
  cron: "0 9 * * MON-FRI"        # 9 AM weekdays

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.

Timezones are first-class; the same workspace can run an India schedule (Asia/Kolkata) alongside a US-East schedule (America/New_York) without manual UTC offsets.

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 force ON (block any scheduled stop) or force OFF (block any scheduled start) for a defined time window. Overrides are time-bounded; an admin-configurable maximum duration 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.

Every override action (create, manual cancel, automatic expiry) is captured in the audit log with actor, timestamp, and reason. Notifications fire on the attached channel when an override is set, cleared, or expires.

Smart Tags integration

Non-prod estates are routinely under-tagged, which makes them hard to scope a schedule to. 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 are applied inside ZopNight only, never written back to your cloud, and each derived value stays pending until you accept it. See Smart Tags.

Anomaly detection

This is schedule-state anomaly detection: it watches whether resources are in the state their schedule expects, on a short (15-minute) cycle. It is distinct from the daily, five-dimension cost anomaly detection on the Cost Graph, which watches spend rather than power state.

ZopNight watches every state transition against what the schedule expects. The anomaly detector runs every 15 minutes (configurable) and surfaces:

• Resources that should be stopped but are running
• Resources that should be running but are stopped
• The schedule that was expected to fire
• The decision source that drove (or failed to drive) the transition

Anomalies are exposed via the Prometheus metric anomaly_detected_count and surface on the audit log and notification channels. Anomalies are the fastest way to spot a permission gap, a cloud API outage, or a misconfigured schedule.