Your Outscale VMs run 168 hours a week. You need 50.

Your dev VMs are running right now.

It's Saturday. Nobody's working. Your staging environment has been burning compute since Friday at 6pm and won't be touched until Monday at 8am. That's 62 hours of paid compute that produced exactly nothing.

This isn't a bug. It's the default. Every 3DS Outscale customer has this problem. And most solve it by doing nothing — or worse, by locking into reserved instances that mask the waste with a smaller unit price.

There's a simpler answer. It's called on-demand, and it's the entire reason the cloud exists.

The math nobody does

A week has 168 hours. A typical dev or staging environment is used 8am to 6pm, Monday through Friday. That's 50 hours of real usage.

50 out of 168. You're paying for 118 hours of nothing.

That's a 70% waste. Not a rounding error. Not a "nice to optimize someday." Seventy percent of your compute bill on those machines is buying you empty cycles.

Now compare that to a reserved instance. Outscale's best reserved instance discount? Somewhere around 30–40% off on-demand price, depending on the term and instance type. And you pay it 24/7/365, whether you use the machine or not.

Scheduling beats reserved instances by a factor of two. You save 70% by running only when needed, versus 30–40% by locking in a lower hourly rate and running always.

Reserved instances have another problem

Outscale's reserved instance policy has been shrinking. A few years ago, you could reserve for 3 years. Then it dropped to 2. Now it's 1 year only.

Every time the term shortens, the discount shrinks. And every commitment is a bet: a bet that this instance type, in this region, at this capacity, will still be what you need in 12 months.

If your infrastructure changes — if you right-size, migrate, or restructure — that reservation becomes a sunk cost. You're paying for a machine you no longer want, at a "discount" that's now more expensive than not having reserved at all.

Scheduling has no commitment. No term. No bet. You change your mind on Monday, and your schedule changes on Monday. Zero risk.

What scheduling looks like in practice

In Vextnd, you set a schedule in a few clicks:

• Pick the instances (one or many)
• Set the hours: start at 08:00, stop at 18:00
• Set the days: Monday through Friday
• Done

One view shows every scheduled instance, its status (running/stopped), and its next transition. No cron jobs. No shell scripts on a bastion host. No "I forgot to restart staging and the team can't work."

The scheduler handles start and stop automatically. If an instance is already in the right state, it skips it. If a start fails, it retries. You get a clean audit trail of every action.

Where scheduling makes sense (and where it doesn't)

Schedule these:

• Dev environments (the obvious one — 70% savings)
• Staging / QA environments (same pattern, same savings)
• Batch processing machines that run on a known cadence
• Demo environments spun up for sales calls
• Training / sandbox instances used during business hours only

Don't schedule these:

• Production workloads with 24/7 traffic (use reserved instances here — that's what they're for)
• Databases with persistent connections and slow cold-start
• Stateless workers behind auto-scaling groups (let the scaling handle it)

The honest answer: most teams have 30–60% of their fleet in the "should be scheduled" category. The savings from scheduling that portion alone usually exceed what reserved instance commitments save on the rest.

The real on-demand promise

Cloud was supposed to mean "pay for what you use." Somewhere along the way, it became "pay for what you provision." The difference between those two is your waste margin.

Scheduling closes that gap. Not by negotiating a better unit price, but by eliminating the hours you don't need. The cheapest compute is the compute you don't run.

Vextnd brings this to 3DS Outscale — the scheduling layer the console doesn't have. Set up in minutes, savings visible within 24 hours.