Add a single event that fires once all workflow runs for a commit/PR have completed

[ranyhb]

Why are you starting this discussion?

Product Feedback

What GitHub Actions topic or product is this about?

Workflow Configuration

Discussion Details

The ask

One signal — a trigger or a webhook — that fires when all workflow runs for a given commit / PR head SHA have reached a terminal state.

Completion, not success. I need to know the pipeline is done, whatever the outcome.

Why this isn't the existing requests

There are several older threads asking for something adjacent, and I want to be explicit that this is not a duplicate of them:

• #25535 — trigger when all checks pass (combined status)
• #61466 — trigger when all status checks are complete
• #171336 — trigger when required checks are successful
• #148873 — whether workflows trigger check_run / check_suite / status events

Those are all asking for a gating primitive: "tell me when everything went green." This request is for a completion / aggregation primitive: "tell me when everything has finished, pass or fail." The use case is analysing a finished pipeline — you specifically need the failures, so success-gated triggers cannot serve it.

Why today's events don't cover it

Every event GitHub exposes here is per-item. workflow_run, check_run, workflow_job and status each fire once per individual item. There is no aggregate.

check_suite looks like the exception, because the documentation describes it as "All check runs in a check suite have completed, and a conclusion is available." That reads exactly like the aggregate signal — but a check suite is scoped per app per workflow run, not per commit.

Concretely, on one of our pull requests, a single head SHA had 20 check suites, 6+ of them from github-actions alone:

total_count: 20
app=github-actions   runs=8    ← one workflow run
app=github-actions   runs=1    ← another
app=github-actions   runs=1    ← another
app=github-actions   runs=1    ...

So check_suite.completed has the same granularity as workflow_run.completed. I would gently suggest the docs wording for check_suite is misleading on its own merits and worth correcting regardless of this request — it strongly implies a per-commit aggregate that does not exist.

A related trap for anyone attempting this: of those 20 suites, 13 were permanently queued with runs=0 — apps subscribed to the repository that never create check runs at all. So you cannot converge on check suites either; you have to converge on check runs, which only exist once an app actually reports.

The only available workaround, and what it costs

The fan-in pattern: trigger on workflow_run: [completed], and on every single fire query the Checks API to ask "is everything else done yet?" — exiting immediately if not.

That means one full workflow run spawned per completed workflow, purely to discover there is nothing to do.

The arithmetic is per push. A pull request with 10–15 workflows spawns 10–15 extra runs, of which all but one are no-ops. At a moderately busy organisation seeing 100–200 pushes a day, that is on the order of 1,500–3,000 workflow runs per day whose only purpose is to start up and exit immediately. This is the recommended workaround, so the same multiplier applies to everyone who adopts it.

That is a large amount of runner scheduling, queueing and Actions minutes, and the cost is borne by GitHub's own infrastructure at least as much as by the user.

It also carries correctness traps that make it fragile rather than merely wasteful:

• workflow_run requires an explicit workflows: list, and there is no glob support for it. The docs enumerate the keys that accept glob patterns — branches, branches-ignore, tags, tags-ignore, paths, paths-ignore — and workflows is absent from that list.
• Because of that, the list silently rots whenever anyone adds a workflow. And if the unlisted workflow happens to be the one that finishes last, the downstream workflow never fires at all. Silent failure, no error.
• There is no workflows-ignore to invert the problem, even though the very same event already has branches-ignore.
• check_run / check_suite cannot substitute, because they do not trigger workflows when the check suite was created by GitHub Actions (documented recursion prevention) — which is precisely the case for every Actions workflow.

Proposal

Ideal: an aggregate event — e.g. checks_completed / workflow_runs_completed — on a commit or pull request, firing once when all workflow runs have reached a terminal state, ideally with a configurable quiescence window so late-starting workflows don't cause a premature fire.

Failing that, two much smaller changes would remove most of the pain, and both match precedent that already exists on this very event:

1. Glob support in workflows: — branches, tags and paths already accept globs; workflows is the odd one out.
2. A workflows-ignore: key — pure symmetry with the branches-ignore already available on workflow_run.

Either of those makes the fan-in workaround maintainable at scale. The aggregate event makes it unnecessary.

Happy to provide more detail on the measurements above if useful.

[github-actions[bot]]

Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided.

This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers.

[hoangperry]

This is one of the most-requested Actions gaps, and the reason none of the adjacent features solve it is worth stating in your request so it doesn't get closed as a duplicate: workflow_run fires per-workflow, check_suite completion is unreliable for multi-workflow aggregation, and there's no primitive for "the whole commit's CI is now terminal." So the ask is legitimate. Until it exists, here are the patterns that actually work:

1. Poll the combined status/check-runs for the head SHA from a lightweight watcher (a scheduled job, or an external service):
   • GET /repos/{o}/{r}/commits/{sha}/check-runs → treat done as every run in status: completed.
   • GET /repos/{o}/{r}/commits/{sha}/status for the legacy commit-status rollup.
     Done = no runs still queued/in_progress. This is the standard implementation of "pipeline is done, whatever the outcome" and it matches your "completion, not success" requirement exactly.
2. Self-aggregate with a gating job. If all the workflows are yours, add one final job that needs: every other job (or a reusable "collector" workflow triggered by each), with if: always() so it runs regardless of upstream success/failure. When it runs, the pipeline is done — and it can emit your single signal (dispatch, notify, set a status). The catch (and worth noting in the FR) is that this only covers workflows you control and can wire together; it can't observe third-party/app checks on the SHA, which is precisely why a native event is needed.
3. check_suite: completed + reconciliation: subscribe to it but debounce — wait for a short quiet period with no new runs on the SHA before declaring done. Hacky, but it's how several CI orchestrators approximate this today.

For the feature request itself, the crisp framing is: a workflow_group_completed (or webhook) keyed on head SHA, firing once when the count of non-terminal runs for that SHA hits zero, reporting aggregate conclusion — because today every consumer reimplements the polling in #1, and none of it can see checks they don't own.

[ranyhb]

U r right, but instead of going indirectly, why not to have a single "indicator" that fires once all are finished..

[Lxcardoza993]

The native "one signal when everything for a SHA is done" doesn't exist yet — but you can build it today with workflow_run + the Check Runs API in roughly 20 lines.

Design: a dedicated "hub" workflow triggered via workflow_run types: [completed] for each tracked workflow. Every time any tracked run finishes, the hub lists all workflow runs for github.event.workflow_run.head_sha, checks whether every tracked run has reached a terminal state, and writes one aggregated Check Run to that SHA. PRs/commits then show a single gate: "Pipeline done — 3 succeeded, 1 failed".

name: pipeline-hub
on:
  workflow_run:
    workflows: [CI, Test, Deploy]   # names of the workflows to track
    types: [completed]

jobs:
  aggregate:
    runs-on: ubuntu-latest
    permissions:
      checks: write
      actions: read
    steps:
      - name: Aggregate run statuses for head SHA
        env:
          GH_TOKEN: ${{ github.token }}
        run: |
          SHA="${{ github.event.workflow_run.head_sha }}"
          RUNS=$(gh api "/repos/${{ github.repository }}/actions/runs?head_sha=$SHA&per_page=100"             -q '.workflow_runs[] | select(.display_title != "pipeline-hub") | .status')
          PENDING=$(printf '%s
' "$RUNS" | grep -Ev 'completed|cancelled|skipped|failure|success' | wc -l)
          FAILS=$(printf '%s
' "$RUNS" | grep -c 'failure')
          CONC="success"; [ "$PENDING" -gt 0 ] && CONC="in_progress"; [ "$FAILS" -gt 0 ] && CONC="failure"
          gh api -X POST "/repos/${{ github.repository }}/check-runs"             -f name="pipeline-complete" -f head_sha="$SHA"             -f status=completed -f conclusion="$CONC"             -f 'output[title]=Pipeline execution finished'

Caveats I hit when deploying this:

• The hub workflow file must live on the default branch to receive workflow_run events.
• A workflow_run caused by a pull_request hands the hub a read-only token, so the Check Run write needs the explicit permissions: checks: write above.
• The hub fires once per tracked run as each completes; that's fine because the aggregation is idempotent. Exclude the hub itself by name (done above) or it self-counts.
• Per-workflow-status granularity: gh api .../actions/workflows/<id>/runs lets you force an explicit tracked-list rather than trusting .display_title.

Worth voting this idea up — a native all-workflows-complete event would remove the indirection — but the hub gives you the exact "done, whatever the outcome" signal today. If this unblocks you, marking it as the accepted answer helps others find the playbook. 🙌

[ranyhb]

Thats it, there are many solutions that we can do but they are all are indirect, we need that in today's era.