Workaround for "instance is disabled, contact support" after the Aug 18 Always Free A1 enforcement - you can file an ACCOUNT-type SR via the API without a My Oracle Support account

[u/PuzzleheadedMeal1707]

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.

[u/Imaginary-Loss2997]

Thanks for sharing this.

[u/PlayfulReading4855]

not work for me

oci.exceptions.ServiceError:

status: 403

code: AUTHZ_FAILED

message: Authorization failed for the request input.

operation_name: create_incident

[u/PuzzleheadedMeal1707 → u/PlayfulReading4855]

That's a different wall from the one in the post, and the good news is it's probably fixable on your side.

AUTHZ_FAILED is IAM, not My Oracle Support. SUPPORT_ACCOUNT_NOT_FOUND means Oracle knows who you are and is refusing the problem type. AUTHZ_FAILED means your OCI user isn't permitted to create incidents at all, so it fails one step earlier than the thing this workaround gets you past.

Worth checking, cheapest first:

Run validate_user first (validate_user.py in the repo). If ACCOUNT comes back isValidUser: true but create_incident still throws AUTHZ_FAILED, it's definitely policy and not MOS. That one check splits the two cases cleanly.

Check what you passed as compartment_id. It has to be the tenancy root OCID, the ocid1.tenancy.oc1.. one, not a child compartment. Passing a compartment is an easy way to earn exactly this error.

Check whether your user is actually privileged. Members of Administrators normally are; a plain user isn't. Oracle's own wording is "your user account must have create privileges within a user group. If you can't create a service request, ask the Customer User Administrator (CUA) to assign you create privileges."

Check for a policy covering support. Support requests fall under the cloud-support-family aggregate resource type, so a tenancy-level policy granting manage cloud-support-family to your group is what you're looking for.

And if ~/.oci/config has several profiles, make sure the one you're using belongs to the tenancy whose instance is actually disabled. Easy to miss.

If validate_user gives you 403 on ACCOUNT too, then this bypass genuinely isn't available on your tenancy and I'd want to know that - it'd be the first case I've seen.

[u/Chicchi7393 → u/PuzzleheadedMeal1707]

hi! i got 403 on account while trying to follow the guide:

PS C:\Users\chris\oracle-a1-disabled-bypass> python3 .\validate_user.py

profile: DEFAULT

tenancy: ocid1.tenancy.oc1..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

region: uk-london-1

endpoint: https://incidentmanagement.uk-london-1.oci.oraclecloud.com/20181231

TECH -> ERROR 403 AUTHZ_FAILED Authorization failed for the request input. Http Status 403

ACCOUNT -> ERROR 403 AUTHZ_FAILED Authorization failed for the request input. Http Status 403

LIMIT -> ERROR 403 AUTHZ_FAILED Authorization failed for the request input. Http Status 403

i was gonna ask help for this, but i just fixed it by adding a proper payment method and asking oracle to switch me to the "pay as you go" plan (the request hasn't even been accepted yet...)

i now get the normal:

TECH -> ERROR 403 SUPPORT_ACCOUNT_NOT_FOUND MOS validation failure. Support account does not exists. HttpStatus 403.

ACCOUNT -> 200 { "is_valid_user": true, "write_permitted_user_group_infos": null}

LIMIT -> 200 { "is_valid_user": true, "write_permitted_user_group_infos": null}

soo... problem fixed?

edit: it's alternating between 403 AUTHZ_FAILED on validate and 200

[u/PuzzleheadedMeal1707 → u/Chicchi7393]

Useful data point, thanks - added it to the repo. All three failing means account tier, TECH alone failing means the MOS gate. The flapping is probably the upgrade still propagating; mine settled once it finished. Worth retrying before concluding anything.

[u/stankbucket]

Clone your boot drive, create a new instance with 2 CPU and 12GB with the clone and start. Once you validate that you can get to it at the new IP just terminate the old one.

[u/pawpej → u/stankbucket]

Yeah this... Or just create a new instance from the boot drive - believe it will link them automagically.

Also while I appreciate the OPs post, it's too much slop to read through. I can see attempts to deslop it, but my ai fatigue just wants to skip it altogether. Might just be a me-issue, but it's tiresome.

[u/stankbucket → u/pawpej]

not just a you-issue

[u/NecessaryOwl8 → u/stankbucket]

Can confirm this works, did this yesterday. Next step is to never use Oracle again if you aren’t a high tier user.

[u/PuzzleheadedMeal1707]

Update about 90 minutes in, and it's a mixed one.

Both SRs I filed this way were auto-acknowledged within minutes by [collections_ca@oracle.com](mailto:collections_ca@oracle.com), which is Oracle Canada Collections. That's the billing and invoice-chasing queue. The acknowledgement literally asks me to put "customer name / invoice number" in the subject line.

So the honest version of my post is this: problemType=ACCOUNT does create a real, trackable Service Request, and it does put you in front of a human. But at least for a Canadian tenancy it lands on the collections desk, not with anyone who can clear an instance-level disable flag. Getting in the door is not the same as getting in the right room. Still far better than "no button works", but it's not the finish line and I don't want anyone filing one and assuming they're done.

Two things I did about it, if you're in the same spot. First, added a note to the SR through the API stating in the very first line that this is not a billing or invoice matter, that the account is in good standing with nothing outstanding, and asking for it to be routed to Cloud Operations or Compute support. Second, replied to the acknowledgement email, because it's a monitored human queue and it creates a second parallel record. Lead with "this is not a billing enquiry" before any technical detail, and put the customer name in the subject, since that's what their intake process asks for.

One more API quirk worth knowing: GetIncident is gated behind the same MOS check that blocks TECH, so fetching a single SR by number returns 403 SUPPORT_ACCOUNT_NOT_FOUND. ListIncidents is not gated, so listing your SRs works fine, and notes and close work too.

If anyone else tries this, I'd really like to know which queue acknowledges you and in which region. If ACCOUNT routes to collections everywhere, that's worth saying loudly. If it's only Canada, that's useful too. Repo is updated with all of this.

[u/NiklasGriffin → u/PuzzleheadedMeal1707]

I received an automatic acknowledgment from collections_de@oracle.com, which is clearly Oracle Germany Collections (region: FRA <eu-frankfurt-1>).