GitHub Actions has become a cornerstone of modern continuous integration and continuous delivery (CI/CD) pipelines, yet developers frequently encounter scenarios where workflows fail to execute. These failures manifest in various forms: workflows remaining perpetually in a "queued" state, abrupt cancellations due to billing restrictions, or silent failures caused by security configurations. Understanding the root causes of these disruptions requires a multi-faceted approach that examines account status, repository configuration, trigger logic, and platform-wide service health. When an Action does not start, the issue is rarely random; it is typically the result of a specific constraint or error state that can be systematically identified and resolved.
Billing Restrictions and Account Limits
One of the most common reasons for GitHub Actions to stop working is billing-related restrictions. When a user’s billing account encounters issues, GitHub pauses Actions workflows to prevent unpaid resource consumption. This pause is not a technical glitch but an enforcement mechanism for the platform’s usage policies.
The primary indicator of a billing issue is a prompt directing the user to check their bill. For free-tier users, this often raises questions about the duration of the free trial, monthly limits, or the maximum number of runs allowed per account. Free accounts are allocated a specific monthly credit for Actions minutes. Once these credits are exhausted, or if there is a payment failure on a paid plan, workflows are suspended.
To resolve billing-induced blocks, users must navigate to the "Billing & plans" section of their GitHub account. The troubleshooting process involves several critical steps:
- Check for payment failures. If a credit or debit card was declined, a warning will appear. Users must click "Retry payment" or update the payment method to restore service.
- Add a valid payment method. If no card is on file, adding one is necessary to enable billing capabilities, even if the account remains within the free tier.
- Adjust spending limits. Some accounts may have a spending limit set to $0. Increasing this limit does not immediately charge the user; it only allows charges to occur if usage exceeds the free quota.
In some cases, users report that simply re-adding the same credit card details forces a payment retry and restores functionality. One community report indicated that workflows resumed approximately three hours after a successful payment was processed by re-entering card details. While some users attempted to open support tickets, the resolution often occurred without direct intervention from GitHub support, highlighting the automated nature of billing enforcement. It is worth noting that the lack of an immediate "re-charge" button for emergency cases has been a point of frustration for teams, particularly when payment issues occur over weekends or across distributed departments, leading to unexpected work stoppages.
Workflow Queuing and Service Degradation
Another frequent symptom of non-functioning Actions is workflows remaining in a "queued" state indefinitely. When a workflow is queued, it means the runner is assigned, but the job has not yet started execution. This can be caused by local configuration errors or broader platform-wide issues.
Platform Outages and Maintenance
Before assuming a local configuration error, developers must verify the health of the GitHub platform. Outages can affect Actions, Codespaces, Copilot, and Packages simultaneously. For instance, on April 23, 2026, GitHub experienced a significant degradation affecting multiple services.
The incident timeline revealed a cascade of issues:
- At 14:40 UTC, reports of degraded availability for Copilot and Webhooks were investigated.
- By 14:41 UTC, Actions performance degradation was confirmed.
- At 14:42 UTC, Packages and Codespaces also showed degraded performance.
- At 14:51 UTC, users experienced errors loading web pages, and Actions and Copilot Cloud Agent runs were delayed.
- A mitigation was applied by 15:02 UTC, with services recovering and Actions working through queued work.
- By 17:04 UTC, the degradation affecting Actions and Copilot was fully mitigated.
Similar incidents have occurred with Copilot Coding Agent and Issues, where root causes were identified and mitigated within hours. During these periods, workflows may appear frozen or stuck in a queue not because of user error, but due to resource constraints on GitHub’s end. Checking the official GitHub status page is the first step in diagnosing such issues. If an outage is reported, the only recourse is to wait for resolution.
Local Configuration and Repository State
If the platform is healthy, the "queued" state may stem from repository-specific issues. Workflows can remain queued if they are disabled. This is common in forked repositories, where all workflows are disabled by default for security reasons. Users must manually enable workflows in forks to allow execution. Additionally, in public repositories, scheduled workflows are automatically disabled if no repository activity has occurred in 60 days. This inactivity timeout is a security measure to prevent dormant repositories from becoming vectors for abuse.
Trigger Logic and Branch Security
A more subtle cause of non-starting workflows involves the interaction between triggers, branches, and security policies. Developers often modify workflow files in feature branches rather than directly in the default branch (e.g., main or master) to adhere to best practices involving pull requests. This workflow can lead to unexpected behavior, particularly with scheduled triggers.
Scheduled Workflows and Default Branches
Scheduled workflows, defined using the schedule trigger, behave differently depending on the branch they are defined in. If a scheduled workflow is defined in a non-default branch (such as a feature branch used for a pull request), it will not run when merged or when the schedule triggers. This is a deliberate security measure.
The logic behind this restriction is to prevent malicious actors from creating a pull request with a scheduled workflow that runs arbitrary code on the target repository. If a scheduled workflow could run on a pull request branch, an attacker could inject malicious code into a schedule that executes on the main repository’s infrastructure. Therefore, GitHub ensures that scheduled workflows only run on the default branch.
To fix this, users must ensure that their scheduled workflow definitions are merged into the default branch. Until the changes are merged into main, the schedule will not activate. This behavior extends to other triggers like pull_request, status, issue, label, and comment. Understanding these caveats is crucial for new users who may expect their workflows to run immediately upon pushing to a feature branch.
High Load Delays
Even when configured correctly, scheduled workflows may experience delays. GitHub Actions infrastructure can experience high load periods, particularly at the start of every hour. During these times, scheduled triggers may be delayed. To minimize the risk of delay, developers can schedule their workflows to run at less congested times, such as the 15th or 30th minute of the hour, rather than at the 00 minute mark.
Diagnostic Checklist
When faced with a non-working GitHub Action, a systematic diagnostic approach ensures the root cause is identified efficiently. The following checklist covers the most common failure points:
- Check Billing Status: Verify if the account has exceeded its free minute quota or if a payment method has failed. Resolve any billing alerts immediately.
- Verify Platform Health: Consult the GitHub status page to rule out ongoing outages or degradation affecting Actions, Webhooks, or other integrated services.
- Inspect Workflow State: Ensure the workflow is not disabled, especially in forks or public repositories with 60+ days of inactivity.
- Review Trigger Configuration: Confirm that scheduled workflows are defined on the default branch. Check if the trigger matches the current event (e.g., push, pull_request).
- Check for Branch-Specific Filters: Ensure that branch filters (e.g.,
branches: [main]) in the workflow file align with the branch where the code is being pushed. - Retry and Wait: If the workflow is queued due to high load or recent platform mitigation, waiting or manually restarting the workflow may resolve the issue.
Conclusion
GitHub Actions failures are rarely without cause. Whether the issue stems from a billing restriction, a platform-wide outage, or a misconfigured trigger on a non-default branch, each scenario has a distinct diagnostic path. Billing issues require immediate attention to payment methods and quotas, often resolving within hours of correction. Platform outages demand patience and verification via the status page, as infrastructure load and mitigation efforts can delay execution. Configuration errors, particularly those involving branch security and scheduled triggers, require a deeper understanding of GitHub’s security model, which prioritizes the protection of the default branch. By methodically addressing these areas, developers can restore their CI/CD pipelines and prevent future disruptions.