Outcome
By the end of this lesson, you will be able to assign the right schedule pattern to each of dev/test/stage/prod, estimate the cost reduction from environment-aware scheduling, and adapt the patterns for global / async / 24/7 teams.
| Prerequisites | T1.M1.3 (schedules) · M3.1 (tagging strategy) |
| Time | 9 minutes |
1. Concept
Nothing else in non-production saves as much as a schedule.
Most teams run dev, test and staging around the clock, not as a decision but because nobody ever set them to do anything else. They were started once and never stopped.
Putting each environment on hours that match how it is actually used usually removes 60 to 70% of non-production compute, and no engineer notices anything change.
ENV TYPICAL SCHEDULE RATIONALE─────────────────────────────────────────────────────────────────dev 8 AM - 8 PM weekdays Engineers iterate during work hours; off-hours useless
test Off entirely after work + Tests run on schedule, Off all weekends not on-demand Scale up on-demand for CI batches
stage Pre-deployment hours only Used briefly before each (e.g., 10 AM - 4 PM weekdays) prod deploy; rare otherwise
prod Always-on Customer-facing; no scheduling unless explicitly non-24/7Following this pattern: a ~$3/mo non-prod resource drops to ≈ $1/mo. Multiply by hundreds of resources.
Why each pattern
DEV environment: longest active hours Engineers iterate; need responsive infrastructure Off-hours (evening, weekend): minimal value Pattern: 8 AM - 8 PM weekdays = 60 hours/week active (vs 168 hours always-on) Savings: ~64% reduction on schedulable resources
TEST environment: more aggressive CI test runs are batchable; engineer attention isn't continuous Most teams: tests run in batches at work hours Pattern: 8 AM - 6 PM weekdays + on-demand spin-up for CI batches ~50 hours/week active Savings: ~70% reduction
STAGE environment: short windows Used briefly before each prod deploy Most teams deploy 2-5x/week; each deploy uses stage 1-2h Pattern: 10 AM - 4 PM weekdays = ~30 hours/week active OR on-demand only (zero baseline; spin up per-deploy) Savings: ~82% reduction
PROD environment: no scheduling Customer-facing; downtime = revenue impact Pattern: 24/7 always-on Exception: explicitly non-24/7 SaaS (B2B office-hours) Exception: regional shutdowns (e.g., Asia prod off during their night if no Asia customers)The pattern is the floor: most teams further refine based on observed usage.
Variations by team working pattern
GLOBAL TEAMS (engineers across timezones) Dev runs ~16 hours covering East to West coast or Europe to Asia Example: 6 AM ET - 10 PM ET, i.e. to 7 PM PT (~16 hours active) Savings: ~50% (still significant; less than co-located teams)
SINGLE-REGION TEAMS (one timezone) Dev runs 12 hours during working hours Example: 8 AM - 8 PM local, Mon-Fri Savings: ~64% reduction
ASYNC TEAMS (engineers work irregular hours) Dev mostly always-on except weekends Example: 24/5 (Mon 6 AM - Fri 10 PM) Savings: ~30% (weekends only; weekday off-hours preserved)
24/7 TEAMS (SRE on-call, ops) Dev technically always-on for incident response But: most incidents touch prod, not dev Pattern: dev still scheduled; on-call has wake-up authority OR: small "always-on" subset for on-call Savings: 40-60% with thoughtful subset selectionThe right schedule depends on the team’s actual working pattern, not assumptions. Audit a week of actual usage before deciding.
Schedule + groups
In ZopNight a schedule applies to the resources and resource groups you attach to it explicitly. Tags do the finding; groups do the attaching:
GROUP: dev-env (members: the resources behind environment=dev on Cost Reports → Tags)GROUP: test-env (environment=test)GROUP: stage-env (environment=stage)
SCHEDULE: dev-workhours Window: 8 AM - 8 PM ET, Mon-Fri Action: stop outside window; start at window-open Attached: group dev-env
SCHEDULE: test-batched Window: 8 AM - 6 PM ET, Mon-Fri Action: stop outside window Attached: group test-env
SCHEDULE: stage-prerelease Window: 10 AM - 4 PM ET, Mon-Fri Action: stop outside window Attached: group stage-env
NEW resources: Do not join a group on their own Add them to the right group (a weekly check: list the resources behind each environment tag value, compare with group members)This is why M3.1 (tagging) is the prerequisite: clean tags make finding each environment’s members a single filter. A resource belongs to one group at a time.
Cost impact by environment
For a typical mid-size org’s non-prod compute:
BEFORE SCHEDULES (24/7 always-on): dev resources: $25K/mo test resources: $12K/mo stage resources: $8K/mo TOTAL non-prod: $45K/mo
AFTER ENVIRONMENT-AWARE SCHEDULES: dev resources: $9K/mo (64% reduction) test resources: $3.6K/mo (70% reduction) stage resources: $1.4K/mo (82% reduction) TOTAL non-prod: $14K/mo (69% reduction)
ANNUAL SAVINGS: ~$372KENGINEER IMPACT: zero (schedule aligns with working hours)
THE ROI: 0% engineering cost to enable; pure savings.The non-prod-scheduling lever is the single largest fast-win in most FinOps programs.
Exceptions and edge cases
CASE: TEST runs in CI need responsive infra SOLUTION: scale-to-one (next lesson, L2) instead of full shutdown Or: CI triggers warm-up 5 minutes before batch Or: keep small permanent footprint for fast spin-up
CASE: STAGE used by external integrators (24/7 visibility) SOLUTION: keep stage running; add internal stage-internal for internal use; schedule the internal one
CASE: DEV used by global team SOLUTION: 16-hour stretched window OR per-region dev environments with regional schedules
CASE: PROD has light traffic at night (B2B office-hours app) SOLUTION: scale to fewer replicas at night (M3.2.L2 scale-to-one) NOT full shutdown unless contract allows
CASE: Database / stateful resources SOLUTION: caution: stopping databases can lose state, slow restore Often: leave databases running; schedule compute only Or: use serverless / auto-pause databases (Aurora Serverless, DynamoDB on-demand)Every team has exceptions. Plan for them; don’t avoid scheduling because of them.
Schedule rollout: 4-week plan
WEEK 1: Audit + plan Identify all non-prod resources Group by environment (via tags) Estimate cost per environment Survey teams: when do you use dev? test? stage? Identify exceptions
WEEK 2: Pilot Pick one team's dev environment Apply dev-workhours schedule Measure: cost reduction, engineer feedback (any disruption?) Tune schedule if needed (extend window for late-night sessions, etc.)
WEEK 3: Expand Roll out dev-workhours to all teams Roll out test-batched to all test envs Communicate via #eng-platform Set up alerting for unexpected wake-ups (cost spikes off-hours)
WEEK 4: Verify + iterate Confirm cost savings match estimate Address any team-specific issues Document the schedule patterns in team wiki Schedule quarterly review for refinementMost teams capture 50-60% of the savings in week 3; final 10-15% in tuning over the next quarter.
2. Demo
An illustrative schedule rollout at a mid-size SaaS company:
TEAM: platform org (200 engineers, US + EU teams)
BEFORE: All non-prod resources 24/7 Non-prod compute: $46K/mo
SCHEDULES DEFINED:
dev-platform-aws: 8 AM - 8 PM ET, Mon-Fri Attached: group dev-platform-us (env=dev, us-east-1 members)
dev-platform-eu: 8 AM - 8 PM CET, Mon-Fri Attached: group dev-platform-eu (env=dev, eu-west-1 members)
test-staging: Mon-Fri 8 AM - 6 PM ET only (US team) + scheduled CI batches at 3 AM + Mon-Fri 8 AM - 6 PM CET (EU team) Attached: group test-env
stage-prod-verify: 10 AM - 4 PM ET + 10 AM - 4 PM CET, Mon-Fri Attached: group stage-env
production-platform: Always-on (no schedule) Attached: none (prod stays out of every group)
AFTER (4 weeks in): dev: $25K → $9K (-64%) test: $13K → $6.2K (-52%) stage: $8K → $2.9K (-64%) prod: $42K (no change)
TOTAL non-prod savings: $27.9K/mo = ~$335K/year Engineer disruption: 2 incidents in first 2 weeks - Late-night engineer hit dev being off (resolved by extending window to 10 PM for that team) - CI batch hit test being off (resolved by adding pre-batch warmup) Both fixed within hours of report.
Net team satisfaction: high (cost savings visible; minor friction resolved quickly).The pattern is repeatable: define per-env schedules, roll out, monitor, refine.
3. Hands-on (5 min)
Map your environment schedules:
□ STEP 1: Current state per environment dev: Hours/week active: _____ Cost/mo: $_____ test: Hours/week active: _____ Cost/mo: $_____ stage: Hours/week active: _____ Cost/mo: $_____ prod: 24/7 (no change) Cost/mo: $_____
□ STEP 2: Proposed schedules dev schedule: __________________________ test schedule: __________________________ stage schedule: __________________________
□ STEP 3: Estimate savings dev savings: $_____/mo test savings: $_____/mo stage savings: $_____/mo TOTAL annual: $_____
□ STEP 4: Identify exceptions Global team coverage needed? __________ CI batches that hit off-hours? __________ External integrators using stage? __________
□ STEP 5: Pilot plan Pick: which environment to pilot first? __________ Owner: __________ Pilot duration: _____ weeksA 20-minute audit reveals the savings opportunity. Most teams find 50-70% savings on schedulable non-prod.
Do it through MCP. A task from this lesson, asked in one sentence.
BEFORE A ZopNight account with one cloud connected, and resource groups dev-env, test-env and stage-env built from your environment tags.ASK "Create dev-workhours (08:00-20:00 Mon-Fri), test-batched (08:00-18:00 Mon-Fri) and stage-prerelease (10:00-16:00 Mon-Fri) in America/New_York, attach the dev-env, test-env and stage-env groups, and leave prod unscheduled."CHECK that no prod resource sits in an attached group. A schedule acts only on what is attached to it, so prod is safe only if it is in none of those groups.Tools behind it: create_schedule (write, tier 2, reversible), attach_group_to_schedule (write, tier 2, reversible), list_schedules (read, Operate). Connection details are in the MCP integration docs.
4. Knowledge check
Q1
Production schedule typically:
A. Always-on
B. 8 AM - 8 PM
C. Business hours, with a weekend stop
D. Weekend off
Show answer
Correct: A. Production is customer-facing, so scheduling rarely applies. The exceptions are explicitly non-24/7 SaaS (B2B office-hours apps) and regional shutdowns where a region has no customers overnight.
Q2
Test environment vs dev environment scheduling:
A. Same schedule
B. Test is always-on
C. Test is scheduled far less aggressively than dev, since test runs are unpredictable in timing
D. Test is MORE aggressively scheduled; test runs are batchable; engineer time isn’t needed continuously
Show answer
Correct: D. Dev is more lenient (engineer iteration). Test can off-hour entirely with on-demand spin-up for CI batches; dev stays up during work hours. Different patterns. Test more aggressive than dev.
Q3
Global team’s dev environment:
A. Always-on, because someone somewhere is always working on it at any hour
B. Stretched window: 16-hour active window covering coast-to-coast or US-to-EU
C. Two separate schedules, one per region
D. Off most of the time
Show answer
Correct: B. The off-hours portion (~8h) is still recoverable, so stretch the window rather than run always-on. Better still: per-region dev environments with regional schedules.
5. Apply
ZopNight Schedules + Groups. Find each environment’s resources by tag, put them in a group, and attach the per-environment schedule to the group. Most non-prod compute drops 60-70% within a month.
For your team: audit this week; pilot next week; full rollout in 4 weeks.
Related lessons
- L2: Scale-to-one pattern (next)
- L3: Rolling test environment
- L4: Freeze windows
- L5: Demo / prod-like environments
- T1.M1.3: Schedules basics