What is preemptible capacity and why is it cheap?
Preemptible instances let you use OCI spare capacity at a steep discount, roughly half the standard on demand rate (indicative, confirm against current pricing). The trade is that OCI can reclaim the instance when it needs the capacity for paying on demand or committed workloads. You get a short signal through the instance metadata, then the instance is stopped or terminated. In return for accepting that interruption risk, you pay far less per hour.
The buyer takeaway is that the discount is real and large, but it is conditional. It only translates into savings on work that can absorb a sudden stop without losing data or failing a customer commitment.
Which workloads fit preemptible capacity?
The fit is determined by one question: what happens if this instance disappears in the next minute? If the answer is nothing important, because the work is checkpointed, idempotent, and restartable, preemptible is a strong fit. If the answer is a dropped transaction or a corrupted state, it is not.
| Good fit | Poor fit |
|---|---|
| Batch data processing and ETL | Stateful production databases |
| CI and build farms | User facing application tiers without redundancy |
| Rendering and simulation | Long single threaded jobs with no checkpoints |
| Stateless workers behind a queue | Anything with a strict uninterrupted runtime |
How do I make a workload reclaim safe?
Three patterns turn a fragile job into a preemptible friendly one. Checkpoint progress frequently so a reclaimed instance loses minutes, not hours. Make every task idempotent so re running it produces the same result, which lets a fresh instance pick up cleanly. And pull work from a durable queue rather than assigning it to a fixed instance, so reclamation just returns the unfinished item to the queue for another worker. Watch the metadata signal and drain gracefully when it arrives.
Worked example: a nightly batch pipeline
A media company runs a nightly transcoding pipeline that takes about 200 instance hours on standard capacity. Moving the restartable workers to preemptible capacity at roughly half the rate, while keeping a small standard baseline to guarantee the job completes, the blended cost falls sharply.
| Design | Hours | Relative cost |
|---|---|---|
| All standard | 200 | 100 percent baseline |
| 90 percent preemptible, 10 percent standard baseline | 200 | about 55 percent |
The job runs the same length on average; occasional reclamations slow it slightly rather than failing it, because the standard baseline keeps it alive. The result is close to a 45 percent cut on this workload. Figures are indicative and verified against anonymized billing data; your blend depends on reclamation frequency in your region.
The decision you can make this week
List the workloads that are stateless, restartable, or already queue driven, and estimate their monthly compute hours. Move the most clearly fault tolerant one to a preemptible fleet behind a small standard baseline, add checkpointing if it is missing, and measure the blended rate over a couple of weeks. If the saving holds and the reclamation rate is tolerable, extend the pattern to the rest of your batch and CI estate.
Frequently asked questions
Put preemptible capacity to work safely
Our buyer side guide identifies which OCI workloads can move to preemptible capacity, how to make them reclaim safe, and what the blended saving looks like across your fleet. We take zero provider commissions, so the advice follows your architecture, not a quota.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.