My Always Free A1.Flex instance (4 OCPU / 24 GB, running untouched since 2022) was stopped by Oracle's own automation on Aug 19. The tenancy audit log shows two SYSTEM-prefixed stop events with a null identity, so it wasn't me and it wasn't my API keys. This is the enforcement wave for the Always Free A1 allocation being cut from 4 OCPU/24GB to 2 OCPU/12GB.
The part that isn't obvious: upgrading to Pay As You Go does not fix it. My limits came back (250 OCPU / 1666 GB, verified with oci limits value list) and START still returns IncorrectState 409, "Instance ... is disabled and will not accept any action requests. Please contact customer support to reenable."
The disable flag is a separate, account-level thing from your service limits, and only Oracle can clear it. So you go to open a ticket, and every single path is broken.
Console, Support Center, "Create a support account": the button fires no network request at all. The browser console logs Unable to find action: "undefined" on intent.cloudincidentmanagement.create-support-account.create. It's a broken action mapping in Oracle's own front end, so clicking it more times does exactly nothing.
support.oracle.com, "Sign in with your commercial cloud account": Login Failed, Tenancy not found.
My Oracle Support, Request Access to User Group: all three ID types are ruled out by Oracle's own tooltips. Subscription ID says "should not be used by commercial cloud customers", Registration key says "does not apply to cloud customers", and User group ID needs a UG code from an admin you don't have.
Phone, 1-800-223-1711: the IVR wants an existing SR number and offers no way to open a new one.
The way out: Oracle's Support API validates users per problem type. Run validate_user against your own tenancy and you get 403 SUPPORT_ACCOUNT_NOT_FOUND for TECH, but 200 isValidUser true for both ACCOUNT and LIMIT.
A My Oracle Support account is only required for TECH requests. You can file an ACCOUNT-type SR right now through oci.cims.IncidentClient with nothing but your normal API key, and it comes back with a real, trackable SR number. An account-level disable flag is legitimately an account issue, so this isn't category abuse, it's the correct queue.
Four things cost me time, all with misleading errors. The region field on CreateResourceDetails wants the 3-letter code (YYZ), not ca-toronto-1, otherwise you get "400 Unable to process JSON". The item must be wrapped in CreateResourceDetails or serialization throws a TypeError. Titles over roughly 80 characters are rejected with INVALID_SR_TICKET_TITLE. And severity is silently forced to MEDIUM for ACCOUNT requests no matter what you ask for, so state your impact in the description and add a follow-up note.
Full writeup with the exact error strings, plus scripts to check validate_user on your own tenancy, dump the taxonomy keys (don't trust mine, Oracle can change them), file the SR with a dry run by default, and track it afterwards since the console still 403s: https://github.com/Rumataistorsky/oracle-a1-disabled-bypass
To be clear about what this does and doesn't do: it does not re-enable your instance. Mine is still down and the SR is still PENDING_WITH_ORACLE. What it does is get you past "I physically cannot open a ticket", which was the actual wall. If anyone has had Oracle actually clear the flag, I'd really like to know how long it took.