How to schedule OCI instance stop and start after hours

Stopping OCI instances after hours has a native answer today: Resource Scheduler, an Oracle Cloud Infrastructure service that, according to its release notes, shipped on May 21, 2024. Before that, the recipe was a cron job running the OCI CLI on some server. Oracle still documents both options. This post covers what a stopped instance stops billing, how each option is set up, which permissions it needs and when something else makes sense.

What a stopped OCI instance stops billing

Before the schedule, the math. According to the "Resource Billing for Stopped Instances" page of the OCI documentation, it depends on the shape:

• Standard shapes: stopping the instance pauses billing. The stopped instance still counts toward your service limits. The table in Oracle's Compute FAQ includes the standard flexible shapes, billed per OCPU and per GB of memory.
• Dense I/O and HPC: the stopped instance keeps billing, because it preserves its NVMe storage. To end the charge you have to terminate it.
• GPU: the VM.GPU.A10 series pauses billing when stopped; every other GPU shape keeps billing, because it preserves its GPU resources.
• Optimized: on VMs, stopping pauses billing; on bare metal it keeps billing.

Two details change the number. Shutting the instance down from inside the operating system does not stop billing: the documentation asks you to stop it from the Console or the API as well. And the boot volume still exists while the instance is stopped: Oracle's Block Volumes FAQ states that it is billed at standard Block Volume pricing, on top of the instance price.

With an 8am to 8pm weekday window, a standard-shape instance stays stopped for 108 of the 168 hours in a week: 64% of the compute. The formula for any schedule, and what does not drop with everything off, is in shutting down dev after hours. The savings calculator does the math with your VMs.

Option 1: Resource Scheduler, the native scheduler

Resource Scheduler stops and starts resources according to the schedules you create from the Console, the CLI or the API. The "About Resource Scheduler" page lists the supported types: Compute instances, instance pools, Autonomous AI Database, Functions and Base DB Systems. What to know before creating the first one:

• One action per schedule. The CLI command accepts START_RESOURCE, STOP_RESOURCE or BACKUP_RESOURCE, so a working-hours window takes two schedules: one that stops at night and one that starts in the morning.
• The recurrence is written in UNIX cron format or in iCalendar format (RFC 5545).
• Resources are picked from a fixed list of OCIDs (static) or by filters on type, tags and age since creation (dynamic).
• Each schedule handles up to 200 resources. The limit is fixed; with more instances, the documentation says to clone the schedule and split the list.
• The documentation shows schedule times in UTC. For a team in Buenos Aires (UTC−3), stopping at 8pm means scheduling 23:00 UTC. From UTC−4 westward, an 8pm stop already falls on the next day in UTC, and the cron weekdays shift with it.

For an 8am to 8pm window, Buenos Aires time, Monday to Friday, the two cron expressions look like this:

# STOP schedule: 20:00 in Buenos Aires = 23:00 UTC
0 23 * * 1-5

# START schedule: 08:00 in Buenos Aires = 11:00 UTC
0 11 * * 1-5

Permissions: two policies, not one

This is the step most often missed. Creating the schedule does not give it the right to act: the Resource Scheduler IAM policies page states that, by default, a schedule cannot perform actions on the target resources and you have to grant it that permission. Two policies are needed, one for the group that manages schedules and one for the schedule itself as a principal:

Allow group ResourceScheduleAdmins to manage resource-schedule-family in compartment dev

Allow any-user to manage instance in compartment id <compartment_ocid> where all{request.principal.type='resourceschedule', request.principal.id='<schedule_ocid>'}

The second policy is tied to the OCID of each schedule, so a new schedule needs its own condition. When an action fails, the schedule list shows Error as the last run status, and the error details appear on the resource details page.

Option 2: the OCI CLI with cron

The official how-to "Automatically Start and Stop a VM Instance" keeps the classic alternative: install and configure the OCI CLI on a server and schedule these two commands with cron or the operating system task scheduler:

oci compute instance action --action STOP --instance-id <instance_ocid>
oci compute instance action --action START --instance-id <instance_ocid>

It works, but it adds pieces: a server that has to stay on exactly when the others go off, API credentials stored on that machine, and a schedule that lives in a crontab with no change history. If everything that needs a schedule is on OCI, Resource Scheduler does the same without that server. What happens when cron jobs multiply is covered in operating windows in non-prod.

When native is enough and when it is not

If your non-production environments live only on OCI, Resource Scheduler handles the schedule with no servers of your own to maintain, and you do not need another tool for that.

The picture changes when dev and QA also have VMs on another cloud. Each provider has its own scheduler, with a different schedule format, a different permission model and a different place to check whether something failed to stop last night. The schedule is configured once; what repeats every week is checking that it ran everywhere.

Scheduling the shutdown is the easy part. The hard part is knowing, on Monday morning, what did not stop on Friday and why.

How Control Cloud handles it

Control Cloud schedules the stop and start of non-production VMs across every connected cloud, from a single console. Each schedule is a cron expression with its own time zone, so 8pm means 8pm in your city with no UTC conversion, and it picks VMs by ID, by tag or by region.

Every run leaves a row in the audit log: how many VMs matched, how many were stopped, how many were already off and which errors occurred. If a run fails, or the schedule stops finding VMs because somebody renamed a tag, whoever created it gets an email alert. To connect a tenancy with read-only permissions and see what sits in each compartment, the OCI guide has the step by step.