Critical GitHub API Bug: `branch` Filter Fails, Impacting Development Dashboard Examples

Intermittent GitHub API Bug Disrupts Workflow Run Filtering

GitHub's REST API is a cornerstone for automating CI/CD processes and feeding critical data into various developer tools, including custom development dashboard examples. However, a recent and recurring bug is causing significant headaches for developers: the branch query parameter on the GET /repos/{owner}/{repo}/actions/runs endpoint intermittently returns a total_count: 0 and an empty workflow_runs array, even when numerous runs exist for the specified branch.

This issue, actively reproducible as of April 27, 2026, means that automated scripts and tools relying on this filter to fetch specific branch data are failing. The problem is particularly insidious because removing the branch filter reveals thousands of matching runs, confirming the data's presence. The bug's intermittent nature makes it challenging to debug, often leading to ghost failures that disappear minutes later.

The Core Issue: Missing Workflow Runs and Impact on Automation

The expected behavior is for the branch filter to return a non-zero subset of workflow runs specific to that branch. Instead, it frequently returns nothing. This directly impacts CI workflows that use this endpoint to find the latest successful build on a branch – a common dependency for downstream jobs like end-to-end tests.

When the API sporadically returns zero runs, upstream jobs exit with an error, causing a cascade of failures in dependent tasks. This not only wastes compute resources but also forces operators to chase non-existent bugs in their own code, severely hindering developer productivity.

Reproducing the Bug

The original reporter provided a simple curl script to demonstrate the issue:

TOKEN="$(gh auth token)"
for repo_branch in \
 "nebius/soperator:main" \
 "anthropics/claude-code:main" \
 "cli/cli:trunk" \
 "kubernetes/kubernetes:master" \
 "actions/checkout:main"
do
 repo="${repo_branch%:*}"; branch="${repo_branch#*:}"
 base="https://api.github.com/repos/${repo}/actions/runs"
 unfiltered=$(curl -s -H "Authorization: bearer $TOKEN" -H "Accept: application/vnd.github+json" "${base}?per_page=1" | jq -r '.total_count')
 filtered=$(curl -s -H "Authorization: bearer $TOKEN" -H "Accept: application/vnd.github+json" "${base}?per_page=1&branch=${branch}" | jq -r '.total_count')
 printf "%-30s branch=%-10s unfiltered=%-7s branch_filter=%s
" "$repo" "$branch" "$unfiltered" "$filtered"
done

Actual Result (captured 2026-04-27 18:22 UTC):

nebius/soperator           branch=main      unfiltered=21658 branch_filter=0
anthropics/claude-code     branch=main      unfiltered=40000 branch_filter=0
cli/cli                    branch=trunk     unfiltered=26073 branch_filter=0
kubernetes/kubernetes      branch=master    unfiltered=104   branch_filter=0
actions/checkout           branch=main      unfiltered=541   branch_filter=0

The branch_filter count consistently returns 0, despite the unfiltered count showing thousands of runs. The same query for cli/cli?branch=trunk even dropped from 16196 to 0 within minutes during testing, highlighting the intermittent nature.

A Persistent Problem

This isn't a new issue. Related discussions like #24626 (open since 2021) and #53266 point to a long-standing pattern where API filters (including status=) suffer from similar intermittent failures, often attributed to underlying search indexing issues.

Side Observation: Undocumented head_branch= Parameter

During testing, it was also noted that the undocumented head_branch= parameter is silently ignored, returning the unfiltered total regardless of its value. While not the primary bug, this behavior can mislead users attempting to find workarounds, as it provides no error feedback.

Immediate Workaround: Client-Side Filtering

Until GitHub resolves the underlying issue, the most reliable workaround is to remove the branch filter from the API request and perform the filtering client-side. This involves fetching all workflow runs (or a larger subset) and then programmatically filtering them by the head_branch property in the response. While this adds processing overhead and potentially increases API call volume, it ensures accurate results.

What This Means for Development Dashboards and Productivity

Reliable API data is fundamental for accurate development dashboard examples that track CI/CD health, deployment statuses, and overall project progress. When core API filters are unreliable, the integrity of these dashboards is compromised, potentially leading to misinformed decisions and wasted engineering effort. GitHub's prompt resolution of this recurring bug is crucial for maintaining trust in its API and supporting robust developer workflows.