Schedule start and stop on a single EKS, GKE, or AKS namespace using ZopNight namespace-level scheduling. Keep platform namespaces online while dev and qa stop overnight.
This is the practical version, the one you can follow in a single sitting. It starts read-only, touches no production resource by default, and every step is reversible, so there is no point at which you are committed to something you cannot undo. Budget about 20 minutes. Before you start you will want: A ZopNight account with a connected EKS, GKE, or AKS cluster; Cluster role binding that lets the ZopNight controller scale workloads and manage HPAs and PDBs in the target namespace; Org admin rights to create schedules.
The steps
- Open the cluster in ZopNight.
- Create a namespace-level schedule.
- Confirm the Stop action plan.
- Confirm the Start action plan.
- Enable the schedule.
- Add or remove namespaces over time.
Why this is safe to do today
The reason this is a low-stakes change is that nothing here is destructive. Scheduling stops and starts resources; it never deletes them, and your data persists across a stop exactly as it does across a normal reboot. Production is excluded by default, actions run in dependency order, and every state change is logged with what triggered it.
If you want the fuller context behind this task, the FinOps guide covers where it fits, and the AWS EC2 scheduling page shows the same loop applied to a specific resource.
Getting started
Getting started is intentionally low-stakes:
- Connect your cloud provider with a read-only role. Nothing is scheduled or changed at this stage.
- Let ZopNight discover your non-production resources and review exactly what it found, filtered by account, region, and status.
- Create a schedule in your timezone and attach the non-production resources or groups you want it to cover.
- Watch the first cycle run, with Slack, Teams, or Google Chat notifications on every start, stop, and failure, then layer in idle cleanup and guided rightsizing.
Production stays excluded by default throughout, and because discovery and recommendations are read-only, you can prove the value before you enable a single action.
Questions we get a lot.
If yours isn't here, email us and we'll answer directly.
Why is the default namespace excluded?
The default namespace often hosts ad-hoc workloads from operators or test pods. Excluding it from scheduling avoids accidental shutdowns of debugging resources. Workloads that belong on a schedule should live in a dedicated, schedulable namespace.
What happens to a CronJob mid-run on Stop?
Suspended CronJobs that already have a Job running will not have that Job killed. The Job runs to completion. Only future CronJob ticks are suspended. On Start, the CronJob un-suspends and the next tick fires per the cron expression.