How to Check If Your Oracle Cloud A1 Free Tier Instance Just Got Quietly Downgraded

Bob Tong — Fri, 21 Aug 2026 04:36:19 +0000

If you're running an Ampere A1 instance on Oracle Cloud's Always Free tier, it's worth logging into the console today. Oracle has quietly reduced the free A1 compute allowance, and starting August 18, 2026, it began enforcing the new limit — including, in some reported cases, against instances that were technically already compliant.

What Actually Changed

The Always Free allocation for VM.Standard.A1.Flex dropped from 4 OCPUs / 24GB RAM to 2 OCPUs / 12GB RAM across your entire tenancy. In Oracle's billing terms that's 1,500 OCPU-hours and 9,000 GB-hours per month, down from 3,000 / 18,000.

The two E2.1.Micro (AMD x86) always-free instances are untouched — still up to two, still 1/8 OCPU + 1GB each.

It's a Tenancy-Wide Budget, Not a Per-VM Cap

This trips a lot of people up. The 2 OCPU / 12GB is a total across all your A1 instances, not a ceiling per instance.

Compliant examples:

1 instance at 2 OCPU / 12GB
2 instances at 1 OCPU / 6GB each
1 instance at 1 OCPU / 4GB + 1 instance at 1 OCPU / 8GB

Non-compliant:

Your old single 4 OCPU / 24GB box
Two instances that together exceed 2 OCPU / 12GB
Check Your Own Tenancy

Console → Compute → Instances → filter for A1.Flex → sum up OCPU and memory across everything you have running.

Instance A: 1 OCPU / 6GB

Instance B: 1 OCPU / 6GB

Total: 2 OCPU / 12GB ✅ compliant

If your total is over 2/12, or if anything shows as Stopped/Disabled that you didn't stop yourself, you need to act now, not later.

The Part Nobody Announced

The documentation change appears to date back to around mid-June 2026, but enforcement was inconsistent for weeks — over-quota instances kept running, billing still showed $0, and the instance-creation UI didn't reflect the new limits. Then on August 18, Oracle started actually enforcing it.

Post-enforcement, Cloud Customer Connect forums saw two categories of complaints:

Users who were genuinely over quota — expected to be disabled.
Users at exactly 2 OCPU / 12GB — supposedly compliant — who got disabled anyway and had to open a support ticket to get reactivated.

Treat the second category as user-reported anecdotes, not confirmed platform-wide bugs — but they're common enough that "I'm within quota" isn't a guarantee your instance survived the sweep.

Fixing an Over-Quota Setup
Resize in place — shrink 4/24 down to 2/12 directly.
Split — go from one big instance to two smaller ones for flexibility.
Delete unused instances — if you provisioned extras "just in case," reclaim them.
Move to PAYG — if 2/12 genuinely isn't enough, the free allocation stays free, and anything beyond it bills normally.

One catch: an already-disabled instance often can't be resized from the console — you may need Oracle support to reactivate it first. Back up before you touch anything.

One More Wrinkle: PAYG Accounts

Community reports are contradictory here. Some Oracle support replies say PAYG accounts still get 4/24 under Always Free terms; others say the same 2/12 cap applies. The public docs don't currently distinguish PAYG from free-tier for A1 quota purposes. If you're on PAYG, don't trust forum threads — open a support ticket and get it in writing.

Does 2 OCPU / 12GB Still Hold Up?

For most lightweight workloads, yes: WordPress, a handful of Docker containers, n8n, an Nginx reverse proxy, small databases, homelab stuff. Where it gets tight is multiple heavy services running concurrently, larger databases, or local LLM inference — and remember these are ARM cores, so verify ARM64 support before you deploy anything, since that trips people up more than the RAM number does.

Combined with the untouched E2.1.Micro instances (good for monitoring, DNS, a jump host), the free tier is still one of the more generous ones on the market — just don't treat it as your only copy of anything important.

I wrote a longer breakdown with the full before/after tables and step-by-step console walkthrough here: Oracle Cloud Always Free Tier Changes — full analysis

How I Benchmark VPS Servers: My Testing Methodology Explained

Bob Tong — Sat, 01 Aug 2026 05:53:40 +0000

As someone who reviews VPS providers for a living, I get asked about
my testing methodology a lot. Here's my full stack:

Hardware Benchmarks

CPU: Geekbench 6 (single + multi-core)
Disk: FIO with 4K random read/write, 1M sequential
Memory: sysbench memory test

Network Benchmarks

Throughput: iperf3 to 5 global endpoints
Latency: ping + traceroute from 3 ISPs
Real-world: curl TTFB on a standard WordPress install

Why This Matters

Most "review" sites just copy specs from the provider's website.
I actually buy the cheapest plan and run these tests myself.

You can see all my published results at [https://vpsrankings.com/rankings] — I keep
the raw data public so anyone can verify.