Yes — this exact pattern recurs: jobs failing at creation with that message while every billing surface looks healthy. Three checks that people usually miss, all from threads where this got resolved:

1. Read the failure run's annotations, not just the job log. That message arrives as a run annotation. Two recent threads (#208350, #208368) had the same shape — runs blocked before any runner starts, all billing views green — and both resolved through billing: the askers confirmed Actions resumed the moment the payment issue cleared.

2. Check Invoices, not just payment methods. A pending invoice with a failed charge keeps the account in "no valid payment method" state even though the card on file is valid and recent payments show successful. In #208350 an invoice failure produced exactly this, with the spending-limit view looking healthy the whole time.

3. Remove and re-add the payment method. If a payment verification ever failed server-side, the account can stay flagged even after you raise budgets and confirm the card is fine. Adding a new card alongside doesn't always clear it; fully removing the failing method and adding one fresh — or setting PayPal as the default method — restarts verification on a different rail.

Beyond those: an identical case two days ago (#209042) started exactly when the budget hit 100%; raising the budget didn't lift the block, so a stale billing flag looks like the only thing that explains yours too — and that part only support can flip. In your ticket, ask specifically "is there a stuck payment verification or a failed invoice holding a billing flag on my account?" — a one-lookup question for the agent instead of a general investigation.

One nuance given the ARC tag: self-hosted runners don't consume Actions minutes, but this block gates job creation at the account level before any runner assignment — so ARC jobs fail with the same message as hosted ones.

@RICHSEEN — your variant is actually the other branch of this family, and it's more tractable than the invoice one:

"Not enough budget" in the annotation is the spending-limit branch (the full text reads "recent account payments have failed or your spending limit needs to be increased"). No pending invoice + healthy card = nothing failed; you've most likely hit the included quota with the Actions spending limit still at $0 (its default), which blocks jobs at exactly this point. Two checks:

• Settings → Billing and licensing → Usage: is the included minutes/storage actually exhausted for this cycle?
• Same area → Spending limits & budgets: is the Actions limit $0?

If both are yes, raising the limit (a few dollars is enough to unblock) is the direct fix — it requires a valid payment method on file, which you have. The cycle reset also clears it if you'd rather wait.

One note on the re-add attempts: re-adding the same card re-runs the same validation; the variant that has unblocked accounts in this thread family (#208350/#208368) was switching the default method to a different rail (e.g. PayPal). But if your Usage page shows the included quota exhausted, the limit is the real lever and the payment method is a red herring.

@fcr-lgtm @HarshDeshmukh2201 — the thread isn't resolved; you're both in the same two-branch family, and the fastest self-diagnosis is the exact annotation text on a blocked run (the annotations bar on the run page, not the job log):

• If it says "…your spending limit needs to be increased" → check Settings → Billing and licensing → Usage for whether the included quota is actually exhausted, and Spending limits for a $0 Actions limit (the default). Raising it a few dollars unblocks immediately.
• If it says "…recent account payments have failed" → check Invoices for a failed/pending one; the fix that has worked in this family is switching the default payment method to a different rail (e.g. PayPal), not re-adding the same card.

"Budget and payment method appear valid" is exactly what this family looks like from the outside — one of those two pages usually shows a different picture than expected (that was true for @RICHSEEN above: no failed invoice, but the spending-limit branch was the live one). If both checks genuinely come back clean, post your exact annotation wording here — the two variants route to different fixes, and that wording is the discriminator.