When Push Events Fail: Troubleshooting GitHub Actions Workflows in Your Software Development Project

The Case of the Missing Workflow Runs

In the intricate world of a software development project, GitHub Actions are the backbone of automation. However, what happens when the very events designed to trigger your workflows—like a simple git push—are received by GitHub but never initiate a run? This perplexing scenario was recently highlighted in a community discussion, where a user, tarekaahmed-lang, meticulously documented a repository-wide failure of push-triggered workflows.

The core of the problem was clear: GitHub's Events API confirmed push events were arriving, yet the Actions API consistently reported zero push-triggered workflow runs for the repository's entire history. Interestingly, workflow_dispatch (manual triggers) and dynamic dependency graph runs worked perfectly. The workflow configuration itself was minimal and permissive:

on:
  push: {}
  pull_request: {}
  workflow_dispatch: {}

This setup, with no branch or path filters, should have triggered on every push.

Exhausting the Troubleshooting Checklist

Before turning to the community, tarekaahmed-lang had already performed extensive troubleshooting, ruling out common pitfalls such as disabled Actions, inactive workflows, repository being a fork, or branch filter mismatches. The community, specifically eddinos2, provided a comprehensive checklist that covers almost every case of this 'Events says push, Actions says 0' signature. This included:

• Actions enabled for the repository: Verified via gh api repos/OWNER/REPO/actions/permissions.
• Workflow files on the default branch: Confirmed the workflow existed on the default branch (e.g., release/v1.8) and was byte-identical to local copies.
• on.push filters: Explicitly confirmed no filters were present beyond on: push: {}.
• Fork policies: Repository was not a fork.
• Billing/minutes exhaustion: Checked usage reports, well within limits.
• Workflow state: All workflows were active.

Crucially, tarekaahmed-lang systematically measured and ruled out each item on this checklist, providing API command outputs to demonstrate the thoroughness. For instance, checking permissions:

$ gh api repos/OWNER/REPO/actions/permissions
{"enabled":true,"allowed_actions":"all","sha_pinning_required":false}

The Breakthrough: Cross-Repository Comparison

The most compelling piece of evidence came from comparing the problematic repository with two other private repositories on the same GitHub account and plan. Both sibling repositories were experiencing normal push-triggered workflow runs (179 and 156 runs respectively), while the affected repository remained at zero. This comparison effectively ruled out account-level or plan-level issues, narrowing the problem down to something specific within that single repository's Actions event handling.

Even a direct test, pushing to a new slash-free branch (ci-probe) to investigate if a slash in the default branch name (release/v1.8) was the culprit, yielded the same result: a PushEvent recorded by the API, but no corresponding workflow run. This further solidified the conclusion that the issue was repository-wide and not configuration-dependent.

Conclusion: A Call for Backend Insight

With all configuration-level and common troubleshooting steps exhausted, the community concluded that the problem likely lies deeper—a disconnect between the GitHub Events API and the Actions dispatcher for that specific repository. This highlights a critical point for any software development project: sometimes, even with perfect configuration and exhaustive checks, an underlying platform issue can impede workflow performance. The recommendation was to contact GitHub Support to inspect the repository's Actions event-delivery state, as this level of detail is not exposed through public APIs. This case serves as a valuable insight into the limits of self-service troubleshooting and when to escalate to platform experts.