Actions stopped dispatching any new workflow runs repo-wide since a specific timestamp (push, pull_request, reopen all unaffected)

[luistrillo-coder]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

Since 2026-09-28T06:20:37Z, GitHub Actions has stopped dispatching ANY new workflow run on our private repository (Team plan org), across every branch and every trigger type we tried:

• Normal push events to feature branches: no run created (not even queued).
• • pull_request synchronize after a push: no run created.
• • An empty commit pushed specifically to retry the synchronize event: no run created.
• • Closing and reopening the PR (to fire a reopened event): no run created.
• • A push to main via a squash-merge, right at 06:20:37Z, DID dispatch and complete successfully - that is the last run we have, out of 676 total runs on the repo.
    What we've ruled out:
• Included Actions minutes: far from the cap (well under half used this billing period).
• • Repo not archived/disabled; workflow state is active (checked via GET /repos/{owner}/{repo}/actions/workflows).
• • Organization-level Actions policy: "Allow all repositories" / "Allow all actions and reusable workflows", nothing restrictive changed.
• • Our API token's rate limit: nowhere near exhausted.
• • Public githubstatus.com: "All systems operational", Actions component green, no unresolved incidents.
• • GET /repos/{owner}/{repo}/actions/runs?status=queued and ?status=in_progress: both empty (no backlog, it's simply not creating run objects at all for new events).
    This has now lasted ~1h with zero workflow_dispatch-eligible workaround available (our workflow only triggers on push/pull_request, no workflow_dispatch), so we can't even manually kick a run via the API to test further.

Has anyone else seen a sudden, total stop of Actions run creation for a single repo/org like this in the last hour, not reflected on the status page? Happy to share the exact org/repo and run IDs privately with a GitHub staff member if that helps investigate.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[kittimzhe]

Your triage is thorough, but it only checks minutes — and minutes and storage are two separate quotas. Storage is the likely tripwire here:

• Team plan included storage is small: 2 GB for Actions artifacts, pooled and shared with Packages (cache is a separate 10 GB/repo allowance). It's billed on an hourly-accrual model, so "current" storage keeps creeping up mid-cycle even with no behavior change on your side.
• The documented enforcement is a hard block, not failed runs: "If your account does not have a valid payment method on file, usage is blocked once you use up your quota." With a payment method on file, a budget / spending limit can produce the same block. "Usage is blocked" matches your symptoms exactly — events stop creating run objects at all: nothing queued, nothing in progress, workflows still report active.

The timing also fits: your 06:20:37Z squash-merge run was the last event before the stop. If the artifacts it published (or a Packages upload into the same pool) pushed current storage over the included amount, everything after that moment would be blocked.

Three things to check in org Settings → Billing & Licensing:

1. Actions usage — look at the storage number (GB), not the minutes. Check Packages too, since it draws from the same pool.
2. Payment methods — an expired or declined card counts as "no valid payment method" for enforcement purposes, even though the plan itself is paid.
3. Budgets / spending limits — a $0 (or low) cap on Actions blocks usage the moment the quota is exhausted.

If storage turns out to be the cause: deleting old artifacts (from the run page or via the API) drops current storage immediately and future accrual stops — runs should resume without contacting anyone. (Artifact retention settings can keep this from recurring.) If all three come back clean, then it's the invisible-state case like #208956 — ask support directly whether the repo or org is flagged.

[luistrillo-coder]

Thanks, this is a great lead and matches the symptoms exactly (hard block, nothing queued/in-progress, workflows still reporting active). Good news is we already have the actual number, not just "in principle" - I re-checked our org's usage page just now:

• Actions storage: 0.6 GB used / 50 GB included (this org's actual entitlement, not the generic 2 GB you mentioned - possibly a different plan/grandfathered allowance). Way under the cap.
• • Actions minutes: 19,887 / 50,000, also far under.
    So storage/minutes quota exhaustion is ruled out with real numbers on this org, not just assumed. Haven't specifically checked payment method validity yet, but given the storage number alone already contradicts the hard-block theory, I don't think that's it either.

Given all three come back clean, this looks like the invisible-state case you linked (#208956) - will follow up with support directly. Appreciate you taking the time to lay out the checklist either way, it's a solid one for anyone else landing here with the same symptom.

[kurupdevs]

One more thing worth ruling out before you escalate to support: a workflow file with a YAML parse error will stop creating runs entirely — no queued runs, no failures, workflows still report active via the API. The symptoms match exactly.

Since your cutoff is pinned to a squash-merge to main at 06:20:37Z, check whether that merge touched anything under .github/workflows/. Even a config tweak with a tab instead of spaces or a misplaced key silently kills run creation for that workflow. Quick checks:

1. Pull the current workflow file and validate it locally, e.g. python -c "import yaml,sys; yaml.safe_load(open('.github/workflows/your-file.yml'))" — note this only catches syntax errors, not bad action refs, but it's a fast first pass.
2. Check the repo Audit Log around 06:20Z for any changes to workflow files or Actions settings.
3. Make sure no on: trigger filters (like paths: or branch filters) were introduced in that merge.

If the YAML is clean and the audit log shows nothing, then yeah — this is the invisible-flag case and support is the only way to get eyes on the backend state. Ask them to check whether the repo or org was flagged by the abuse-detection automation.

[citronfundation]

Closing the loop for anyone who lands here with the same pattern (general Actions outage recovers, but one specific PR/branch keeps getting zero pull_request runs afterward).

Thanks @kittimzhe and @kurupdevs for the storage and YAML-syntax theories — both ruled out in our case (storage well under quota, workflow file unchanged across the whole range).

What it actually was for us: the general outage was real and did recover on its own around 10:09Z. But the one PR that stayed stuck had, separately, picked up a genuine merge conflict against the base branch — introduced by an unrelated merge to main that happened to land almost the same second the outage started, which is what made us initially (wrongly) attribute everything to the outage.

GitHub does not dispatch pull_request-triggered workflow runs while a PR has an unresolved merge conflict (mergeable: CONFLICTING) — no error, no queued run, nothing. We confirmed this two ways: gh pr view <n> --json mergeable showed CONFLICTING, and we opened a throwaway PR pointing at the exact same commit, which showed the same CONFLICTING state and also got zero runs. Once we merged main into the branch and resolved the conflict, mergeable flipped to MERGEABLE and a normal run appeared within seconds.

So: if a PR is stuck like this and the branch/repo-level checks all look clean, check mergeable on that specific PR before assuming it's an Actions-side "stuck state" — it's an easy thing to miss when you're already primed to blame a recent outage.