ZopNight for SRE Teams: Cost Changes Without New Incidents
From where an SRE sits, a downsize, a stop or a new scaling policy is a production change. It should be reviewed, reversible and observable like one.
Site reliability engineers are accountable for availability and for how the system behaves when things fail. Cost optimization is, from that seat, a stream of changes: instances resized, schedules stopping things, scaling policies rewritten. The questions an SRE asks are the same as for any change. What does it touch? What happens when it fails? Can it be undone? This page answers those for ZopNight, including the gaps.
What a change will touch
Blast radius analysis runs from a recommendation, an autoscaler policy or a schedule before you apply it. It walks one hop out from the target over edges inferred from metadata (shared security groups, load balancer targets, attachments, triggers) and classifies each neighbour. For a stop, attached storage is safe and a database-access link to a database is a warning, because connections are terminated; for a delete, members of the deleted parent are affected. Anything not explicitly proven safe is a warning. It does not see actual traffic or know how many other load balancer targets exist, and it says so. See blast radius explained.
What happens when an action fails
A failed start or stop is retried automatically up to three times, then placed on a dead-letter queue, and surfaced in the action status so the UI shows the error. Separate notification events fire for a failure and for exhausted retries, so you can page on the second only. Remediation errors are classed as permission or quota problems, transient failures that can be retried, or unsupported calls.
Two limits to plan around today. ZopNight does not alert when a resource’s actual state drifts from its schedule, so keep your own monitoring on anything that must be up. And EKS, GKE and AKS start and stop run as a single call, with no automatic recovery if a long cluster operation is interrupted; failed actions still surface as notifications.
Scaling you can adopt gradually
Autoscaler policies for Auto Scaling groups, VM scale sets, managed instance groups and ECS services have three modes: monitor (observe only), recommend (suggest, you apply) and autopilot. A read-only account can only use monitor mode. Existing cloud policies can be adopted without any cloud-side change, and applying a ZopNight policy saves the previous configuration so removing it restores the original. For planned peaks, Event Readiness pre-scales and then restores the original sizes, and never changes databases.
Reliability findings, not just cost
Kubernetes workload rules include a reliability category: missing requests and limits, degraded workloads, single-replica deployments and HPAs pinned at maximum. Fixing a single-replica deployment is guided-only; ZopNight never auto-scales a workload you chose to run as a singleton. See reliability recommendations.
During an incident
An override forces a resource or group on for a set window, so a schedule cannot stop something you are debugging. Cost anomaly root-cause analysis includes schedule failures among its causes, and state history shows who or what changed each resource and when.
Questions we get a lot.
If yours isn't here, email us and we'll answer directly.
Will ZopNight overwrite our existing autoscaling policies?
Not silently. If a target already has cloud-side policies, you choose adopt or replace. Replace saves the prior configuration so removal restores it, and it refuses shapes such as predictive scaling that it cannot reconstruct.
Does ZopNight alert if a scheduled resource is running when it should be stopped?
Not today. The schedule-versus-actual drift check is not wired to any alert, so rely on your own monitoring for that case.