Feature Request: Search GitHub Actions Runs by Workflow Run Name

[amitsahniemis]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

Problem

GitHub Actions run history can currently be filtered by actor, branch, status, and event. However, there is no way to search workflow runs by their displayed run title (run-name).

Many organizations use dynamic run names to embed deployment metadata such as environment, component, version, branch, region, or release identifier. In repositories with large deployment volumes, locating a specific run requires manually paging through workflow history, which slows down troubleshooting and deployment tracking.

For example:

run-name: "🚀 [${{ github.event.inputs.environment }}] \
${{ github.event.inputs['component-name'] }} | \
ref:${{ github.event.inputs['component-branch'] || github.event.inputs['component-tag'] }} \
(by ${{ github.actor }})"

Resulting run titles might look like:

🚀 [production] billing-service | ref:v2.4.1 (by amit)
🚀 [staging] patient-service | ref:feature/test-fix (by john)

Currently, there is no way to search for:

production
billing-service
v2.4.1
patient-service

directly from the Actions run history.

Proposed Solution

Add support for searching and filtering workflow runs using the resolved run-name value.
Examples:

run:production
run:billing-service
run:v2.4.1

Or simply include run-name content in the existing Actions search functionality.

Benefits

• Quickly locate deployment runs for a specific environment.
• Search by component, branch, tag, version, or release identifier.
• Reduce manual navigation through paginated workflow history.
• Improve debugging, auditing, and deployment traceability.
• Leverage metadata that teams are already maintaining in workflow definitions.

[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. ⭐

[xusnitdinov]

+1 on this, dynamic run-name is really useful for embedding deploy metadata and it's a shame the UI search can't see it. The examples you gave (searching by environment, component, version) are exactly the use cases where paging through history gets painful.

While you wait on the UI feature, there's a workaround that already works today because the API does expose the resolved run name. The list-runs endpoint returns display_title (the rendered run-name) and name, so you can grep it from the CLI:

# find runs whose resolved run-name contains "billing-service"
gh api "repos/OWNER/REPO/actions/runs?per_page=100" \
  --jq '.workflow_runs[] | select(.display_title | test("billing-service")) | {id, display_title, status, conclusion, html_url}'

Swap the test(...) string for "production", "v2.4.1", etc. You can wrap that in a tiny alias/script so it feels like the run:... filter you're proposing. It paginates too if you loop over ?page=N.

Not a replacement for proper search in the Actions tab, but it should unblock the "I need to find that one deploy run right now" case until the real filter lands.

[amitsahniemis]

Thanks for sharing the workaround. I was aware that the display_title field can be queried via the API, and it's definitely a helpful temporary solution.

However, the goal of this request is to make this functionality available directly in the GitHub Actions UI. Requiring users to install GitHub CLI, know the appropriate API commands, and run them whenever they need to locate a deployment by environment, component, or version adds friction to a workflow that could otherwise be handled through a simple UI search/filter.

Since the metadata is already available via display_title and exposed through the API, it would be great to see the same capability surfaced in the Actions UI for a more discoverable and seamless experience.

Appreciate the +1 and the helpful tip! 👍