New Savings Proposals: approve, test and roll back cost changesLearn more Sign in|Talk to a cloud engineer
Product tourGet a demo

Stop non-production resources outside working hours

Start and stop EC2 instances and RDS instances and clusters by day, time and timezone. A dry run checks each resource before a stop, an approver signs off on new schedules, and every run is recorded.

Get a demoSee recommendations
What you're watching
  1. 1
    Name it and pick the instances

    “staging · office hours” selects EC2 instances by the tag env = staging: staging-web-01 and 17 more.

  2. 2
    Set STOP 20:00 and START 08:00

    Monday to Friday in Asia/Kolkata. The panel shows 108 of 168 hours stopped and $4,120/mo projected.

  3. 3
    Run the dry run

    Supported type, 18 of 18 running, and p95 CPU at 12%, below the 40% safety threshold.

  4. 4
    Submit for approval

    The schedule shows Pending Approval and Marcus is emailed. Nothing stops until he approves.

Who does thisPlatform lead, with an approver from the platform teamWhat you getA $4,120/mo schedule that waits for sign-off before it stops anything.
Projected$6,460/mofrom three sample schedules
Stopped108 hof 168 each week for office-hours staging
ResourcesEC2 + RDSinstances and clusters
SafetyDry runbefore every schedule goes live

Sample data from a fictional company.

Non-production runs 168 hours a week

Most teams only use it during office hours. These are the usual reasons nobody turns it off.

Cost

Non-prod running all night

What usually happens: Staging runs 168 hours a week for a team that uses it about 60, and the other 108 hours look like normal usage on the bill.

How CloudLens resolves it: “staging · office hours” stops 18 instances at 20:00 on weekdays and all weekend, for a projected $4,120/mo.

Resolved
Safety

Stopping something mid-job

What usually happens: A cron script stops instances on a timer, including the one halfway through a data export.

How CloudLens resolves it: Before a STOP, the dry run checks resource type, current state and CPU. Busy resources are skipped and the skip is recorded.

Resolved
Governance

Schedules nobody agreed to

What usually happens: An engineer adds a stop script for a database another team relies on for overnight tests.

How CloudLens resolves it: New schedules start as Pending Approval. The approver approves or rejects with a reason, and the requester is emailed either way.

Resolved

How Priya cut staging cost without blocking a release

One schedule, one approval and one pause during a release week.

PNPriya NairPlatform lead, Lumora Retail

Lumora Retail is a fictional company. The people, names and numbers are sample data.

    1
    Mon 10:00

    Creates the office-hours schedule

    STOP at 20:00 and START at 08:00, Monday to Friday, Asia/Kolkata, covering 18 EC2 instances in staging.
    2
    Mon 10:05

    Runs the dry run

    All 18 are supported types and currently running. CPU is low on 17. One batch runner is busy and would be skipped if it is still busy at stop time.
    3
    Mon 10:10Pending Approval

    Sends it for approval

    The schedule shows Pending Approval, and Sofia, who owns the staging budget, gets an email.
    4
    Mon 14:30Active

    Approved and active

    Sofia approves. The weekly view shows 108 stopped hours a week and a projected $4,120/mo.
    5
    Thu 18:00

    Paused for a release

    A release needs staging overnight, so Priya pauses the schedule. No STOP runs that night.
    6
    Mon 08:00

    Resumed

    Execution history shows Thursday night as paused and Monday’s START on all 18 instances.
Staging still running at 3am?

See what a nightly schedule saves you

Get a demo

A calendar for your cloud, with a safety check

Create a schedule group with STOP and START actions, choose active days, times and a timezone, and CloudLens runs it.

See every schedule’s week at a glance

The weekly view shows running and stopped hours for each schedule side by side, in each schedule’s own timezone, with projected monthly savings. The example covers 18 staging instances in Asia/Kolkata, 9 sandbox instances in New York and 3 QA database clusters in UTC.
  • Weekly on and off view
  • Timezone per schedule
  • Projected monthly savings
What you're watching
  1. 1
    Read one row per schedule

    staging · office hours, analytics-sandbox · weekdays and qa-databases, each with its target, timezone and status.

  2. 2
    Follow the now line

    Solid blocks are running hours and hatched space is stopped by schedule. Weekends stay off for both EC2 schedules.

  3. 3
    Watch the totals climb

    Hours stopped and saved this week count up as the week passes. All three schedules project $6,460/mo.

Who does thisPlatform lead, or the FinOps lead checking schedule savingsWhat you getOne view of when non-production is running, in each team's local hours.

Nothing stops until someone approves it

New schedules start as Pending Approval. The approver approves or rejects with a reason, and the requester gets an email either way. Approved schedules become Active and run at their next window.
  • Pending Approval
  • Approve or reject with a reason
  • Email notifications
What you're watching
  1. 1
    Reject qa-databases · nights

    Marcus rejects stopping 3 RDS clusters at 22:00. His reason: nightly regression runs until Oct 1, so resubmit after.

  2. 2
    Approve analytics-sandbox · weekdays

    The 9-instance schedule becomes Active, with its first STOP today at 19:00.

  3. 3
    Ana is emailed both outcomes

    The rejection carries Marcus's reason. The approval shows the schedule is Active and projects $1,380/mo.

Who does thisPlatform approver, reviewing requests from FinOpsWhat you getOnly approved schedules run, and rejected ones come back with a reason.

Pause, resume and review every run

Pause a schedule during a release freeze and resume it afterwards. Execution history lists every START and STOP with the resources it touched, including any skipped because CPU was above the safety threshold.
  • Pause and resume
  • Execution history
  • Busy resources skipped
What you're watching
  1. 1
    Read the execution history

    Every START and STOP is listed with the resources it touched, such as staging's 20:00 STOP on 18 of 18.

  2. 2
    Spot the skipped instance

    The 19:00 analytics-sandbox STOP reached 8 of 9. One stayed running because CPU was above the safety threshold.

  3. 3
    Pause, then resume

    Pausing staging · office hours stops all actions until it is resumed. After resuming, the next STOP is today at 20:00.

Who does thisPlatform lead during a release weekWhat you getEvery start and stop accounted for, including the instance left running on purpose.

Dry run before it goes live

Checks the resource type is supported, reads its current state and looks at CPU, so a busy instance isn’t stopped mid-job.

Days, times and timezones

Each schedule has its own active days, START and STOP times and timezone, so teams in New York and Bengaluru both get office hours.

Schedule groups

Group resources that belong together, like a staging environment or a set of QA databases, and manage them as one.

Schedules don’t close recommendations

A schedule never closes a recommendation on its own. Idle-resource recommendations stay open until someone decides what to do with them, and schedule savings are tracked separately.

The rest of the savings workflow

01 · Find

Recommendations

Priced per resource, owned and tracked.

02 · Fix fast

Quick Wins

Safe fixes with the command ready.

03 · Change safely

Savings Proposals

Approve, dry-run, apply, roll back.

You are here

Scheduler

Stop non-prod when nobody's using it.

Scheduler questions

EC2 instances, RDS instances and RDS clusters.

That the resource type is supported, what state each resource is in right now, and CPU utilization before a STOP, so busy resources aren’t interrupted.

An approver in your organization. Schedules stay Pending Approval until they approve. If they reject it, the reason is emailed to the requester.

Yes. Pause it and no START or STOP runs until you resume it.

Ready to see CloudLens in action?

Connect a read-only AWS role or Azure service principal. We'll walk you through your bill, your security graph and the first things worth fixing.