workflow_run listener shows 0 runs ever - no trigger fires, not even skipped jobs

[foobarnes]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

Summary

I have a workflow_run listener workflow that has been merged to master (the default branch) for over a week. The worfklow is intended to catch failed workflows across our repository and notify us via Slack. It has never produced a single run record → no active runs, no skipped runs, nothing. The GitHub Actions API confirms total_count: 0:

GET /repos/{owner}/{repo}/actions/workflows/{listener-id}/runs
# → {"total_count": 0, "workflow_runs": []}

The [documentation](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_run) says a working workflow_run listener should produce a run record every time a subscribed workflow completes, even runs where the job is immediately skipped by the if: predicate. I am seeing none of that.

---
Listener (minimal reproduction)

name: "Notifications: Job failure"

on:
  workflow_run:
    types: [completed]
    workflows:
      - "Workflow A"
      - "Workflow B"
      - "Workflow C"
      # ~55 more entries, each exactly matching another workflow file's
      # top-level `name:` value in the same repository

permissions:
  contents: read

jobs:
  notify:
    if: >-
      contains(fromJSON('["failure", "timed_out", "startup_failure", "action_required"]'), github.event.workflow_run.conclusion) &&
      (
        contains(fromJSON('["schedule", "workflow_dispatch", "workflow_run"]'), github.event.workflow_run.event) ||
        (github.event.workflow_run.event == 'push' && github.event.workflow_run.head_branch == 'master')
      )
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - uses: actions/checkout@v4
        with:
          persist-credentials: false
      - name: Notify
        env:
          WORKFLOW_NAME: ${{ github.event.workflow_run.name }}
          CONCLUSION:    ${{ github.event.workflow_run.conclusion }}
        run: echo "Would notify: $WORKFLOW_NAME finished with $CONCLUSION"

Note: the workflows: block uses YAML block sequence style (one entry per line with - prefix) rather than the inline flow style ([Workflow A, Workflow B, ...]) shown in most documentation examples. But that shouldn't matter for YAML parsing.

---

What I have confirmed

• The listener file exists on master - confirmed via git and the GitHub API (state: active, path: .github/workflows/notifications-job-failure.yml)
• Multiple subscribed workflows have completed since the listener was merged, including schedule-triggered workflows that concluded with failure on master → conditions that should satisfy both the trigger filter and the job if: predicate
• actionlint reports zero warnings or errors
• A meta unit test validates that every entry in workflows: exactly matches a real workflow's top-level name field in the same repo and there is no name drift
• The workflow API endpoint for the listener ID specifically returns total_count: 0; the listener has never been enqueued in any state

Per the docs:

▎ "This event will only trigger a workflow run if the workflow file exists on the default branch."

That condition is met. The trigger is simply never firing.

---

What this is not

• Not a job if: condition issue - a false if: predicate produces a skipped run record; we have zero records of any kind
• Not a name mismatch - a meta test enforces exact sync between the workflows: list and actual workflow name: fields; it passes

---

Related discussions

• Workflows triggered by workflow_run are sometimes skipped
• on: workflow_run does not work for me
• Action no longer being triggered by workflow_run
• workflow_run action not being triggered

The above threads cover cases where the listener is enqueued but the job is skipped, or where event delivery is delayed. None cover the case where no run record is created at all for an active listener on the default branch.

---

Question

Has anyone encountered workflow_run silently failing to enqueue, producing no run record whatsoever, despite the listener being active on the default branch and multiple subscribed workflows completing? Is there a configuration condition (list size, YAML style, trigger ordering) that causes GitHub to not enqueue the listener rather than enqueue it and skip the job?

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

[Shovanmondal63]

Yes — there are a few real-world cases where workflow_run simply never enqueues and therefore produces zero run records, exactly like what you're describing. Your debugging already eliminated the common mistakes, so this is probably one of the less-documented edge cases.

The important distinction is:

Job-level if: false → workflow run exists, jobs skipped
Trigger never matched → no workflow run record at all

You are clearly in the second category.

Here are the most likely causes, ordered from most to least probable.

1. workflow_run.workflows only matches workflows that exist on the default branch at event evaluation time

This part is poorly documented and causes silent failures.

GitHub resolves the workflow names in:

on:
workflow_run:
workflows:
- "Workflow A"

against workflows visible on the default branch when the triggering workflow completes.

If any of these are true:

workflow renamed recently
workflow disabled/re-enabled
workflow moved paths
workflow file recreated
workflow run came from an older commit before rename
workflow exists only on another branch during execution
workflow name contains invisible Unicode / spacing mismatch

then GitHub may silently fail to match the trigger.

The especially nasty part:

workflow_run matches the displayed workflow name attached to the completed run, not necessarily the current YAML contents.

So historical runs can fail matching after renames.

2. Large workflows: lists are known to behave unreliably

You mentioned:

~55 more entries

This is immediately suspicious.

There are long-standing reports of workflow_run behaving inconsistently with very large workflow lists. GitHub has never clearly documented a hard limit, but people have observed failures somewhere around dozens of entries.

The silent behavior:

no enqueue
no skipped record
no webhook-visible failure
listener appears healthy

This aligns very closely with your symptoms.

Strong test

Temporarily reduce to:

on:
workflow_run:
types: [completed]
workflows:
- "Workflow A"

Then manually fail Workflow A.

If the listener suddenly works:

you've confirmed a list-size/parser/matching issue.

Honestly, based on your description, this is my leading hypothesis.

3. workflow_run is extremely sensitive to exact workflow name:

You already validated names, but there are still hidden traps:

Examples

These visually look identical:

name: Workflow A

vs

name: "Workflow A "

or Unicode normalization differences.

GitHub stores workflow names internally after parsing. YAML normalization plus Unicode normalization can produce mismatches your meta-test won't catch unless you're comparing GitHub API-returned names.

You should compare against:

GET /repos/{owner}/{repo}/actions/workflows

and validate against the API-returned name field, not raw YAML.

4. workflow_run does NOT trigger from some workflow origins

This is another undocumented-ish behavior.

workflow_run can silently fail depending on how the original workflow was triggered.

Particularly problematic:

fork-originated runs
Dependabot runs
reusable workflows
workflows skipped by concurrency cancellation
workflows that never reach a terminal state properly
organization policy restrictions
GitHub App initiated workflows

You said scheduled workflows failed on master, which should work, so this is less likely.

5. Reusable workflows (workflow_call) can break assumptions

If some of the named workflows are actually wrappers around reusable workflows, GitHub sometimes records names differently than expected.

For example:

visible UI name ≠ emitted workflow_run name
called workflow vs caller workflow confusion

Again:

API inspection of actual completed runs matters more than YAML.
6. YAML style is NOT the issue

This:

workflows:

• "Workflow A"
• "Workflow B"

is completely valid.

No issue there.

7. The listener itself may need a no-op unconditional job

This sounds weird, but there are reports where GitHub optimizes away workflows before enqueue if all jobs are conditionally false-evaluable at planning time.

Try adding:

jobs:
probe:
runs-on: ubuntu-latest
steps:
- run: echo "listener fired"

with no if:.

If this suddenly produces runs:

GitHub is incorrectly short-circuiting evaluation.

I have personally seen Actions do surprising pre-evaluation behavior around event payloads.

8. There is a hidden recursion/anti-loop rule

GitHub aggressively prevents recursive workflow triggering.

You already allow:

workflow_run

inside your predicate:

contains([...], github.event.workflow_run.event)

If some upstream workflows were themselves triggered by workflow_run, GitHub may suppress downstream chaining.

GitHub officially documents some recursion prevention but not all of it.

What I would test immediately
Minimal reproduction matrix

Create:

A
name: Workflow A
on:
workflow_dispatch:

jobs:
fail:
runs-on: ubuntu-latest
steps:
- run: exit 1
Listener
name: Listener

on:
workflow_run:
workflows:
- "Workflow A"
types:
- completed

jobs:
probe:
runs-on: ubuntu-latest
steps:
- run: echo "FIRED"

If this works:

the core feature works in your repo
the issue is your production configuration.

Then add complexity one piece at a time:

add your if:
add more workflow names
add all 60 names

You will likely find the breaking point.

My actual suspicion ranking
Most likely
Huge workflows: list causing silent non-enqueue
Workflow name mismatch at GitHub internal/API level
Historical renamed workflow mismatch
Less likely
Conditional-job optimization bug
Recursion prevention
Reusable workflow weirdness
One more important thing

GitHub Actions has several event systems that behave differently:

webhook delivery
Actions event routing
workflow planner
queueing

workflow_run is one of the least reliable and least observable parts of Actions.

[foobarnes]

I have systematically tried all of the above suggestions to no avail. I cannot get the workflow_run listener to fire.

[Shovanmondal63]

docx.pdf