See inside GitHub Composite Actions - What GitHub doesn't show you

TL;DR:

Composite actions make CI/CD workflows cleaner and more reusable, but they also hide what’s happening inside. GitHub’s API doesn’t expose nested steps or timings, so when a composite action fails or runs slow, you’re left guessing. Orbit unfolds every nested step, no matter the depth. So you can see exactly what’s running, where time is spent, and which processes each step triggers.

Composite Actions: Great for Reuse, Tough to Debug

GitHub composite actions let you combine multiple run steps into a single reusable action that can be shared across repositories.

They’re a great way to:

• Keep workflows DRY by reusing common logic
• Standardise best practices across teams
• Build shared CI components for setup, caching, testing, and security checks

In most teams, reusable composite actions quickly become the backbone of their CI/CD pipelines.

But there’s one problem - visibility.

The Blind Spot

When a composite action runs inside another workflow, GitHub treats it like a single step.

The API doesn’t expose what happens inside, which leads to a few pain points:

• You can’t tell which nested step failed; the whole step just shows as failed
• You have to scroll through raw logs to find the exact error
• The step duration you get from the API is only for the top-level step, not the inner steps
• And with third-party composite action, you have no idea what they’re actually doing unless you review the source manually

The longer or more complex the composite action is, the harder it gets to debug or optimize.

How Orbit Improves This

If you’re running Orbit’s CI agent on your self-hosted or GitHub-hosted runners, this gap disappears. Orbit automatically:

• Captures every nested step within a composite action, no matter how deep
• Records accurate timings and statuses for each step
• Traces all underlying processes, so you can see exactly what was executed

The screenshots above show a GitHub Action Step running a composite action and the OTEL spans generated by Orbit. Nested steps show up as namespaced spans (e.g _self.run-integration-test.setup-gradle). This is especially useful for -

• Understanding third-party actions - see what each one does without reading its source. (https://github.com/marocchino/sticky-pull-request-comment is being used in the composite action)
• Tracing real execution - know exactly which processes run inside every step.
• Finding slow nested steps - pinpoint the exact step inside a composite that’s causing delays.

See exactly what every third-party GitHub Action runs - every process, every command, fully traced.

How Teams Are Using It

Teams using Orbit for GitHub Actions have found this especially valuable for:

• Understanding large “monorepo-style” composite actions shared across repos
• Finding bottlenecks inside reusable actions
• Evaluating third-party GitHub Actions for reliability, performance, and what they actually run

Closing Thoughts

GitHub Composite actions make CI/CD cleaner, but at the cost of transparency.

Orbit gives that visibility back showing every step, process, and dependency inside your actions.

We’ll dive deeper into how the Orbit agent captures this in an upcoming post.

👉 Running GitHub Actions at scale? Install Orbit CI agent and get better observability for your composite actions.