Off-Hours Schedule Recommendations From Real Usage
A schedule finding is a proposed weekly window built from measured running hours, with the before and after drawn side by side.
The schedule category holds findings where the right fix is a recurring start/stop or pause window. It was separated from idle and rightsizing so that scheduling-driven savings can be filtered on their own. Its logic differs from the other categories because a schedule proposal is only as good as the usage history behind it.
The evidence contract
Schedule findings are generated only from the latest 21 days of metrics, and five checks must all pass: the newest datapoint is no more than three days old, history reaches back at least 18 days, at least seven distinct days were observed, at least 24 datapoints exist, and there is no interior gap longer than three days. A new resource therefore waits for a full three-week picture before its first proposal, and an estate whose metric ingestion stops sheds its schedule findings within three days. The known limit: a resource deliberately kept off for more than three consecutive days looks the same as a dead pipeline, and is refused.
How the saving is priced
The saving is the effective rate per running hour multiplied by the running hours the schedule would remove. For accounts with billing data connected, that rate is the last 30 days of billed cost divided by the measured running hours, so negotiated discounts are included. For rack-rate accounts it is the catalog hourly rate. When the resource’s existing schedule already beats the proposal, or its running hours cannot be verified, the finding stays visible as a no-dollar advisory with the derived schedule and the reasoning.
Examples
- GCP VM Non-Production Scheduling and Azure VM Non-Production Scheduling, both of which veto disaster-recovery, standby and stateful workloads. The Azure rule also skips VMs covered by a reservation, since stopping them would not save.
- Azure Dev/Test VM Without Auto-Shutdown and GCP Vertex AI Workbench Notebook Missing Idle Shutdown.
- Idle Azure MySQL Flexible Server and Idle GCP Cloud SQL Instance, where the lever is a recurring park, never a one-shot stop.
- ASG Floor Lock Detected, for an Auto Scaling group pinned at a minimum above one.
- Azure SQL Dev/Test Could Use Serverless Tier, where auto-pause does the scheduling.
From finding to schedule
The drawer shows a weekly utilization panel, one 24-hour column per day, and a today versus after-apply strip. Remediate on a schedule-class finding opens the schedule creator with the resource prefilled and attaches it on save. From there the usual scheduling tools apply: timezones, overrides, groups and notifications, described in resource scheduling. Executing a schedule needs a read + write account. Background: scheduling best practices.
Rule lists per cloud: AWS, GCP, Azure.
Every scheduling check ZopNight runs has its own page, with the reason it fires and the fix: see the scheduling checks in the ZopNight rule catalogue.