Workflow conclusion aggregation

[thbeu]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

General

Discussion Details

I read that GitHub Docs mentions the workflow conclusions. What's missing there is a matrix how GitHub aggregates multiple conclusions to an overall conclusion. Especially the cancelled conclusion needs clarification. Take this commit as an example where 2 cancelled and 3 successful checks lead to a red X symbol ❌ :

cancelled can mean:

• Manual cancellation
• Superseded run
• Concurrency group interruption

Hence, cancelled is not a check failure, but also not a success. The overall check result is kind of inconclusive as it does not lead to a vaild check conclusion. Why is it handled as failure and displayed as ❌ ? Would it be better if handled as inconclusive and ❗ or 🛑 ?

[Roxtop07]

GitHub’s check aggregation logic is effectively this:
• Success → ✅
• Anything else (failure, timed_out, cancelled, skipped, neutral) → ❌ if the check is required

There is no tri-state logic. GitHub does binary gating:

“Is this commit safe to merge automatically or not?”

If the answer is not an unambiguous YES, GitHub returns ❌.

That’s it.

⸻

Why cancelled is treated as failure (even though it isn’t one)

You’re correct:
cancelled ≠ failure
But GitHub isn’t evaluating intent, it’s evaluating merge safety.

From GitHub’s perspective:
• A cancelled run means:
• The workflow did not complete
• Therefore its guarantees were never produced
• No guarantees = cannot assert correctness
• Cannot assert correctness = block merge

So GitHub collapses:
failure
cancelled
timed_out
missing

into the same bucket: “this check did not prove the code is safe”

That bucket renders as ❌.

⸻

Why your example shows ❌ despite more successes than cancellations

GitHub does NOT do majority voting.
It does AND logic, not COUNT logic.

Conceptually:
overall_success =
check_1 == success
AND check_2 == success
AND check_3 == success
AND ...
The moment one required check is not success, the whole expression fails.

So:
• 3 success
• 2 cancelled
→ overall = fail

This is intentional and consistent.

⸻

Why GitHub does NOT have ❗ or 🛑 (inconclusive)

Because it would break automation guarantees.

Think about:
• branch protection
• auto-merge
• required checks
• merge queues
• CI/CD pipelines

These systems need deterministic outcomes:
• merge allowed
• merge blocked

An “inconclusive” state would force humans back into the loop, which defeats the purpose of CI enforcement.

GitHub optimizes for:

“Safe automation over semantic purity”

Even if that annoys people who think carefully about states (like you).

⸻

About your specific cancellation reasons

You listed:
• Manual cancellation
• Superseded run
• Concurrency interruption

You’re right that some of these are benign.

But GitHub does not distinguish intent at aggregation time because:
• The platform can’t reliably infer why it was cancelled
• Treating some cancellations as passable would open merge holes
• Security > convenience

So GitHub chooses the conservative rule:

Cancelled = not proven = block

⸻

Is this a documentation gap?

Yes. Absolutely.

GitHub Docs explain individual conclusions, but they avoid documenting aggregation rules because:
• They are opinionated
• They’re not guaranteed to stay stable
• They don’t want people relying on edge semantics

But the behavior is stable and intentional.

⸻

Would your proposed ❗ be “better”?

Semantically? Yes.
Practically? No.

Because then GitHub would need:
• new merge rules
• new branch protection logic
• new API contracts
• new UI affordances
• human intervention pathways

GitHub is not going to add that complexity.

⸻

The correct mental model (this is the key takeaway)

Stop thinking in terms of:

“Was this run a failure?”

Start thinking in terms of:

“Did this run produce a success signal that GitHub can trust?”

If not → ❌.

That’s the whole system.

⸻

If you want different behavior

Your only real options are:
1. Do not mark cancellable jobs as required
2. Split required vs optional checks
3. Ensure cancelled workflows are retried automatically
4. Use continue-on-error for non-critical matrix entries
5. Collapse matrix jobs into a single required aggregator job

Anything else is fighting GitHub’s design, and you’ll lose.

⸻

[rafaelxo]

This is a valid point regarding how GitHub aggregates statuses.

Currently, GitHub follows a strict 'Success or Fail' logic for the top-level commit status. If any job in a workflow is cancelled, it means the intended CI/CD pipeline did not complete its validation. Because the state is not 'Success', GitHub marks the entire run as failed (Red X) to prevent accidental deployments or merges of incomplete checks.

If you want specific jobs to not affect the overall status when they don't succeed, you can use the continue-on-error: true property in your workflow YAML. This will allow the job to fail or be interrupted without turning the entire workflow status red.

However, regarding your suggestion for a different 'inconclusive' icon: many users have requested more granular status badges. For now, the Red X remains the default for anything that isn't a total success to ensure maximum safety in development pipelines.

[silverwind]

X ... for anything that isn't a total success to ensure maximum safety in development pipelines

What kind of impact does a icon in the UI exactly have on the outcome of a pipeline?

[rinas21]

GitHub aggregates workflow conclusions using strict AND logic for required checks. Any job that isn’t success (failure, cancelled, timed_out, or skipped) blocks the overall workflow. Cancelled jobs aren’t failures per se, but they don’t produce a trustable success signal, so GitHub treats them as ❌ to ensure merge safety. There’s no tri-state or “inconclusive” because automation (branch protection, auto-merge, CI/CD pipelines) relies on deterministic outcomes. To avoid unwanted failures, mark cancellable jobs as optional or use continue-on-error: true.