Replies: 2 comments 2 replies
|
Based on further review on our end, we believe the block may be caused by a stale or orphaned spending-limit restriction on the legacy organization-level budget, separate from the enterprise-managed $2,000 budget. Specifically: Our enterprise-managed budget ($2,000, Stop usage enabled) shows ~$1,000.60 in metered usage β well under the cap. This pattern β enterprise budget with headroom, legacy org budget set to alerts-only, but jobs still blocked pre-execution β suggests either: A restriction flag left over on the organization from when it was migrated to enterprise-managed billing, which the current billing UI no longer surfaces, or Could this be escalated to the Billing platform team specifically to check for (a) an orphaned/stale spending-limit restriction tied to the organization independent of the enterprise budget, and (b) any failed authorization attempt on the saved payment method? Front-line billing support tools don't appear to expose either of these states. We'd like to avoid raising our $2,000 enterprise cap if the actual cause is a stale restriction rather than genuine budget exhaustion. Happy to provide the run ID / logs again if useful β they're already attached to case #4732160. |
|
Hi @mathewsf3, Having your entire merge pipeline blocked by a billing ghost error is incredibly frustrating, especially when your UI says everything is fine. Other organizations have definitely run into this exact combination of symptoms. Since you have just exhausted your 50,000 included Enterprise minutes, you are hitting a known friction point in GitHub's billing engine when it attempts to transition an account from "included" to "paid" minutes. Here are the three most common causes for this silent block and what you can try while waiting on your support ticket: 1. The "1 Dollar" Refresh TrickSometimes, the billing backend fails to sync your spending cap with the Actions execution engine. You can often force the system to recalculate your account state by changing your spending limit slightly.
2. The Dual-Level Spending LimitBecause you are on Enterprise Cloud, spending limits can exist at two levels: the Enterprise level and the individual Organization level.
3. Silent Bank Authorization FailureEven though no error is visible in your GitHub UI, your bank or credit card issuer may have quietly blocked GitHub's initial authorization ping when it tried to switch to paid minutes, flagging it as an unexpected charge.
Regarding Support RoutingSince you are an Enterprise Cloud customer, make sure your ticket (#4732160) was submitted through the Enterprise Support portal rather than the standard community support portal. Enterprise tickets are bound by SLA response times (usually within 8 hours for urgent issues). If you submitted it via standard support, it goes into a much slower general queue. Hopefully, the limit refresh trick gets your deployment pipeline unstuck today! |
Uh oh!
There was an error while loading. Please reload this page.
π·οΈ Discussion Type
Question
π¬ Feature/Topic Area
Other
Discussion Details
Our FluxoKit GitHub Enterprise Cloud account is encountering an Actions billing restriction. Required checks on our private repository fail before any steps execute, preventing our normal validated merges and releases.
Existing support case: #4732160. We have provided the affected run and detailed billing evidence privately in that case.
The job annotation is:
What we verified on September 5, 2026:
We searched and found related reports in #199036 and #151956, but we do not know whether the underlying cause is the same.
Has another Enterprise Cloud organization resolved this combination of symptoms, and what specific supported action restored Actions?
If GitHub staff can help route existing case #4732160 to the appropriate billing/account-review team, we would appreciate it. We need the team to identify any failed authorization, account-level usage restriction, or enterprise/organization billing association problem. If payment is required, please provide the exact amount and action through the private support case. We want to retain our $2,000 hard cap.
We understand that the community cannot inspect private billing state. We are looking for confirmed recovery experience and the correct support route; the account-level cause is still unconfirmed.
All reactions