The math: 168 hours, 60-hour workweek, 64% off

Outcome

By the end of this lesson, you will be able to calculate the theoretical maximum scheduling savings on any non-prod estate and explain the gap between theoretical and realistic savings.

1. Concept

One piece of arithmetic sits underneath this entire course. It takes ten seconds and it decides where most of the money is.

HOURS IN A WEEK                                168
TYPICAL WORKWEEK USEFUL HOURS                   60 (Mon-Fri, 12 hrs each, generous)
RATIO                                       60 / 168 = 35.7%
NON-WORKWEEK HOURS (idle in non-prod)        108 / 168 = 64.3%

If something is only useful during working hours, it sits idle for 64 percent of the week. Stop it during those hours and you stop paying for them.

Most non-production systems fit this shape exactly. Development environments. Staging clusters. Test infrastructure. Reporting databases that only serve office hours.

That 64 percent is the ceiling, not the outcome. Three things pull it down in practice.

1. Some of it genuinely runs overnight. Long test suites and integration runs finish while everyone is asleep.
2. Starting up takes time. The first request after a cold start waits one to three minutes, which is irritating enough that an over-aggressive schedule gets switched off by the people it annoys.
3. Teams are spread across time zones. One working window does not fit everybody.

Allowing for all three, expect to save 45 to 55 percent of non-production compute rather than 64.

Three workweek schedules and what they save

SCHEDULE                       USEFUL HOURS/WK    SAVINGS
─────────────────────────────────────────────────────────────
Aggressive: 9-6, Mon-Fri               45         73%
Standard:  8-8, Mon-Fri                60         64%
Generous:  8 AM-10 PM, M-Sat           84         50%
Weekend skip (Sat + Sun off)          120         28.6%
Always-on (no schedule)               168          0%

The trade-off is friction vs. savings. Aggressive schedules return more but require disciplined override patterns (engineers click “Force on” when they need to work late). Standard schedules are the default sweet spot in most organizations.

What this means for a real bill

WORKED EXAMPLE
─────────────────────────────────────────────────────────────
Non-prod compute spend                  $40,000 / month
Schedule (Standard, 8-8 Mon-Fri)          64% off the non-prod compute
Theoretical monthly savings             $25,600
Realistic at 50%                        $20,000
Realistic at 40% (after friction)       $16,000
─────────────────────────────────────────────────────────────

A team going from 0 to 40 percent realized scheduling savings on non-prod compute, on a $40K monthly non-prod bill, recovers $16,000 per month. $192,000 per year. For one schedule on one tier of resources.

What scheduling is NOT good for

Three workload profiles where scheduling does not help and can hurt:

• Production traffic. Customers do not care about your schedule. Production should not be scheduled off (with rare exceptions for explicitly non-24/7 products).
• Continuous batch. Jobs that legitimately must run nights.
• Anything stateful with long restart cost. Some databases. Some clusters. Some workloads with warm caches that take an hour to rebuild.

For everything else, the math is dominant.

Compounding with rightsizing

Scheduling and rightsizing compound. A non-prod m5.2xlarge that should be m5.xlarge, scheduled off-hours, saves the rightsizing delta (~50% of compute) AND the scheduling delta (~50% of remaining hours). Combined savings on that single resource: ~75 percent.

This is why the lever sequence in M0.2 L3 puts scheduling first and rightsizing second. Each works on the others.

2. Demo

Illustrative numbers from a typical first scheduling rollout:

RESOURCE                       BEFORE         AFTER          REALIZED
                              (on-demand,   (8-8 M-F          MONTHLY
                              168 hrs/wk)   schedule)         SAVINGS
─────────────────────────────────────────────────────────────────────
12× dev EC2 m5.xlarge          $1,728        $617             $1,111
4× staging RDS db.r5.xlarge     $1,440        $514             $   926
2× test EKS cluster (8 nodes)   $2,304        $823             $1,481
1× staging Databricks WS        $1,920        $685             $1,235
─────────────────────────────────────────────────────────────────────
TOTAL                          $7,392        $2,639           $4,753
                                                              (64% off)

One schedule applied to 19 resources. Monthly savings: $4,753. Annual: $57,036. Engineering time to set up: 4 hours.

3. Hands-on (7 min)

For your own non-prod estate, compute the scheduling business case:

STEP 1. Current monthly non-prod compute spend
         (from your cost tool, filter: environment=dev, test, stage)
         = $ ____________

STEP 2. Pick a schedule
         Aggressive (9-6 M-F)  73% theoretical
         Standard (8-8 M-F)    64% theoretical
         Generous (8-10 M-Sat) 50% theoretical

STEP 3. Apply a realism discount (typically 0.7× theoretical)
         Theoretical %     × 0.7   =   Realistic %

STEP 4. Multiply current spend by realistic %
         = $ ____________ /month realistic savings

STEP 5. Multiply by 12 = annual savings
         = $ ____________

The annual number is the business case. Take it to the next FinOps weekly meeting.

4. Knowledge check

Q1

A team has $80K monthly non-prod compute spend. Standard schedule (8-8 M-F), realism discount 0.7×. Realistic monthly savings:

A. $51,200
B. $35,840
C. $28,672
D. $80,000

Q2

A dev environment must support engineers across UTC-8, UTC, and UTC+8. Best schedule choice:

A. Aggressive 9-6 UTC
B. Always-on
C. Standard 8-8 in each engineer’s local timezone (run multiple schedules): or pick a generous window that covers all three
D. A custom schedule for every single engineer, matching each of their own individual working hours precisely

Q3

The math says scheduling saves 64 percent. A team that has scheduled non-prod sees only 28 percent realized savings. Most likely cause:

A. The math is wrong
B. Override usage is high, several long-running batch jobs run nights, and tag coverage is incomplete so some non-prod is not actually scheduled
C. The cloud provider raised its prices during the period, which ate into the savings the scheduling actually produced overall
D. The schedule did not fire

5. Apply

ZopNight surfaces the math directly:

• Schedules → Estimated Savings shows, as you build a schedule, one whole-number percentage: the hours it keeps resources stopped out of the 168 in a week. That is the theoretical figure. It shows no dollar amount and applies no realism discount.
• Costs → Reports → Summary shows the modelled savings from scheduled actions (rack rate of saved hours) beside the cost chart.
• Costs → Flow shows where the remaining spend goes, and its Savings toggle highlights reclaimable spend.

To turn that percentage into money, multiply it by the resources’ monthly cost and apply your own realism discount. The first month’s actual numbers come in via the daily billing sync.

Open ZopNight Schedules (deep link)

Related lessons

• L2: Commitments: what RIs, SPs, CUDs really save (next)
• L4: When scheduling wins, when commitments win
• T1.M1.3: Build your first schedule

Glossary terms touched

Schedule · Theoretical savings · Realized savings