Keeping Your Free Oracle VPS From Getting Reclaimed

You did the hard part. You passed Oracle's fraud check, picked Phoenix, ran the retry script until a 4-core ARM instance finally materialized, and set up your dev box. It's been humming along, mostly waiting for you to SSH in and do something. Then one morning you go to connect and it's not there. Terminated. Reclaimed.

This is the free tier's one genuine catch, and it catches people who did everything else right. Everything about Oracle's Always Free tier is a gift except this: Oracle reserves the right to reclaim instances that look idle, and a dev box that's mostly waiting for you looks exactly like the thing it wants to reclaim. Understanding why is the difference between keeping your machine and re-running the capacity lottery every few weeks.

What "idle" actually means

Oracle's stated policy — and the numbers here are historical, because Oracle has adjusted them before and reserves the right to again — is that an Always Free compute instance becomes a reclamation candidate when, over a 7-day window, it stays below roughly 20% utilization across CPU, memory, and network, measured at the 95th percentile. When all three of those signals sit low for a week straight, the instance gets flagged, and flagged instances can be stopped and reclaimed.

Read that threshold carefully, because the and is doing a lot of work. It's not enough to occasionally spike CPU. The reclamation logic is looking for a machine that is, by every measure, doing nothing — low compute, low memory pressure, low traffic, sustained for seven consecutive days. Oracle documents the current mechanics in its Always Free resources reference, and it's worth checking there rather than trusting any fixed number you read secondhand, this one included.

Here's the trap for a solo builder specifically. A production server serving real users clears 20% without thinking about it. A dev box — the thing you provisioned to tinker on, that sits between your coding sessions doing nothing at 3am on a Tuesday — is precisely the profile the reclamation logic targets. You are not being penalized for abuse; you're being penalized for not having shipped anything yet. The machine that most needs to survive your pre-launch phase is the one most likely to get taken.

The free tier's one string is short: an idle box gets reclaimed, and a pre-launch dev box is idle almost by definition.

The keep-alive pattern

The straightforward defense is to manufacture just enough activity that the machine never trips the idle flag. You don't need to fake a heavy workload — you need to keep the 95th-percentile numbers off the floor. A lightweight cron job that does small, real work on a schedule is the standard approach:

# crontab -e — nudge CPU and network every 10 minutes
*/10 * * * * /usr/bin/openssl speed -seconds 5 >/dev/null 2>&1
*/15 * * * * /usr/bin/curl -s https://example.com >/dev/null 2>&1

The first line runs a short CPU benchmark; the second makes an outbound request to move some network bytes. Neither is doing anything useful, which is exactly the point — they exist to generate a heartbeat. Tune the frequency and duration up if you're cutting it close, down if you'd rather stay lean. The goal isn't to peg the machine at 20%; it's to keep it comfortably clear of "does nothing for seven days."

That's the honest, boring, reliable version. It's a few lines in your crontab and it will very likely keep your box alive.

Why "NeverIdle" scripts are a fragile bet

The community has more aggressive tools for this — packaged keep-alive daemons, "NeverIdle"-style scripts that hold utilization at a target by burning CPU and memory continuously. They work, often better than a modest cron job, and they're one search away.

They're also a fragile foundation, and it's worth being clear-eyed about why. These scripts win a cat-and-mouse game that Oracle can change the rules of unilaterally, at any time, without notice. The reclamation detection is Oracle's code, on Oracle's side of the wall. If Oracle updates how it measures utilization — weights the signals differently, adds a new one, looks at process-level behavior instead of raw counters — a third-party script tuned against the old logic can silently stop working. You'd find out the way everyone finds out: the instance is gone one morning.

There's a second, quieter problem. A daemon that pins your CPU and RAM near a threshold 24/7 is burning your machine's actual capacity to look busy. You provisioned 4 cores and 24GB to do things — spending a meaningful slice of that budget on the performance of not-being-idle is a strange trade. And on a shared free tier, deliberately holding sustained artificial load is exactly the kind of behavior that invites scrutiny rather than deflecting it.

So: community keep-alive scripts are a reasonable stopgap if you understand the bet you're making. Just don't build your dependence on the machine around one, and don't be surprised when a version that "always worked" quietly stops.

The real fix ends the problem for good

Here's the part that reframes the whole issue. The idle problem is self-solving the moment your box is running something real. Every keep-alive trick above is a bridge to get you to that point — and once you're across, you can tear the bridge down.

Think about what actually pushes utilization past 20% naturally:

• A small always-on service — an API, a bot, a scheduled scraper, a Discord or Telegram integration — generates continuous CPU and network activity as a side effect of doing its job.
• A background worker — a queue consumer, a nightly batch job, a monitoring agent — keeps the memory and CPU numbers honest.
• Real traffic, even a trickle of it, moves the network needle in a way no synthetic curl loop needs to fake.
• A waitlist or landing page collecting signups, or a self-hosted tool you reach from anywhere, keeps the box legitimately alive because it's legitimately in use.

None of these are things you'd add to keep the server alive. They're things you'd add because you're building. And the instant you're building on it, the reclamation logic stops seeing an idle machine and starts seeing a working one — because that's what it is.

This is why the framing matters more than the tactic. If you find yourself elaborately engineering a keep-alive script, that's often a signal you haven't given the machine a job yet. The keep-alive is a symptom of an empty server. The cure isn't a cleverer heartbeat — it's a workload.

The short version

The free lunch has one string, and it's short:

• Oracle reclaims instances that stay under ~20% CPU, memory, and network for 7 straight days — historically; the current numbers live in Oracle's docs, not in your memory of this post.
• A pre-launch dev box is idle almost by definition, so this catches builders who did everything else right.
• A modest cron job that generates a small periodic heartbeat is the reliable, honest defense while the box is empty.
• "NeverIdle"-style community scripts work but bet against detection logic Oracle can change without warning — a stopgap, not a foundation.
• The permanent fix is to run an actual workload. Ship something onto the box and the idle problem evaporates on its own.

The whole tension resolves cleanly once you see it the right way. Oracle isn't trying to take your server; it's trying not to warehouse empty machines for people who claimed one and forgot it. Give it a reason to keep yours — a running service, a live page, a job that does real work — and you've turned the free tier's one catch into a non-issue. The machine that's busy building your thing is never the machine that gets reclaimed.

---

Part of the Vibe-entrepreneurs series on solo builder infrastructure. Previously: Oracle's Always-Free Tier: The Server Everyone Forgets. Next: Deploy Global Infrastructure for Free on Cloudflare and Build a Waitlist Page in 30 Minutes, Zero Servers. More builder insights.