Independent CI does not mean the source provider stops existing. If GitHub stores the repository, a new run still needs GitHub to deliver or expose the event and the requested commit.
The useful separation is narrower: GitHub Actions does not parse, schedule, execute, log, cache, or retain the Runnable job. Those responsibilities belong to a different control plane and a different runner fleet.
That changes one broad dependency into several explicit ones—and makes it possible to reason about which incidents stop which work.
The run becomes durable before the machine exists
A signed provider event is admitted into Runnable, matched to a workflow snapshot, and expanded into a stored run graph. Dependencies, matrices, conditions, environments, and concurrency decisions live in the control plane rather than inside a runner process.
A job is provisioned only after the scheduler admits it. The attempt, steps, machine request, and timestamps are recorded before execution begins, which lets startup failures and stale heartbeats become explicit infrastructure conclusions instead of disappearing work.
Independent from Actions is not independent from GitHub
When GitHub Actions is degraded but GitHub repositories, Apps, and APIs remain available, Runnable's parser, scheduler, machines, logs, artifacts, and billing path do not share that Actions failure domain.
When GitHub itself cannot deliver events, mint installation tokens, or serve repository objects, GitHub-backed work can still be affected. Check Run publication may also lag even when Runnable has already reached a conclusion. Runnable preserves its own run record, but it does not pretend the source dependency vanished.
- Runnable ownsWorkflow planning, job admission, machine lifecycle, logs, artifacts, conclusions, and usage records.
- GitHub-backed runs needRepository events or polling, source access, installation tokens, and Check Run delivery.
- Entire-native runs needAn authenticated event relay and access to the selected Entire repository cell.
Failure is a state transition
The scheduler watches startup deadlines, runner heartbeats, provider usage, job timeouts, and cancellation. If a machine never appears, disappears unexpectedly, or stops reporting, the attempt closes with a defined conclusion and the machine is terminated when possible.
That state machine is also what makes retries and reconciliation safe. A network timeout between services does not authorize two machines for the same attempt, and a late callback cannot reopen a completed job.
Redundancy starts with an honest diagram
A second CI path is valuable only when it does not quietly call the first path underneath. Runnable implements the workflow lifecycle independently: GitHub Actions does not parse, schedule, execute, log, cache, or store a Runnable job. Customer commands still retain the public internet access ordinary builds and deployments need.
The remaining provider edges stay visible. Teams can then decide whether GitHub-backed redundancy is enough or whether an Entire-native source path is appropriate for workloads that need a different source failure domain too.