ComposalBrowse documentation
CI
Inspect and troubleshoot
Read CI results, diagnose waiting or failing jobs, and compare runner cost with landing time.
On this page
Find the run and logs
Open a Change’s checks or the repository’s Actions page, select a run, then open the failing or slow job. Read its step output before retrying. A pending check may be waiting for a runner or for another required job; a running job can still be preparing its checkout before the first workflow step begins.
For the candidate being validated by the merge queue, inspect its current checks rather than an older review run:
com queue status
com ci status --commit <candidate>
Use the candidate identity reported by the queue and keep the same repository and organization context. Shared batches link to their shared candidate’s checks. A previous batch is diagnostic history, not passing evidence for the current candidate.
Resolve common problems
| Symptom | What to check |
|---|---|
| No workflow runs | File location, event and branch eligibility, path filters, and compatibility diagnostics. |
| More workflows run than expected | Shadow mode, global or unmapped inputs, policy changes, and incomplete-diff fallback in Selective CI. |
| A required workflow appears missing | Request Run Full CI, review the dependency graph, and ask your administrator to disable selection for the affected scope while it is corrected. |
| A cache misses or makes CI slower | Cache key inputs, runner version, archive size, transfer/extraction time, and the install path on a miss. See Caching. |
| Tests run again after landing | Preview availability, changed workflow/job inputs, runner image, secret versions, retry intent, or artifact-producing jobs. See result reuse. |
| Landing waits despite passing tests | Current candidate checks, approvals, external checks, queue ordering, and target freshness. |
| Jobs wait for capacity | Runner availability and workflow concurrency groups, then candidate concurrency. |
Measure CI performance
Track two outcomes separately: total runner time per landed Change and elapsed time from joining the merge queue to landing. Skipping an unrelated workflow saves runner work, but may leave landing time unchanged if another required workflow takes longer. Runner capacity, approvals, external checks, and publication can also dominate the wait. Shadow mode provides selection evidence but does not save workflow execution time.
Compare similar Changes before and after enabling selection: web-only with web-only, shared-code with shared-code, and warm-cache runs with warm-cache runs. Record selected versus scheduled workflows and conservative fallbacks alongside timings. A lower median for one workflow does not by itself prove faster end-to-end landing. Keep periodic full-CI comparisons, and repeat the configuration checks when dependencies or build tooling change.
Open your repository’s Actions page to compare median and p95 run duration over 7, 14, or 30 days. Choose a workflow to compare its history with the preceding equal-length period. Successful runs establish duration baselines; failures and cancellations are shown separately in the outcome graph.
Where CI spends time ranks jobs by cumulative successful job time. Compare their median, p95, and queue wait, then follow Slowest run to inspect an example. Run duration measures start to finish; job wait measures queued to started. Daily buckets use UTC and run creation date, and missing timings remain empty rather than becoming zero.
Use job and step timings to separate waiting for a runner, preparing the checkout, and executing tests. A job can be running before its first workflow step starts. Include setup time and failed or cancelled attempts when comparing runner cost, and investigate startup failures before increasing queue concurrency.
When measuring through the API, keep timestamps on the same clock. Step started_at and finished_at can come from the runner; a runner's clock may differ from the API's clock. The read-only observed_started_at and observed_finished_at fields record when the API first accepts running and terminal step updates. Use these server observations when comparing steps with server-recorded job or lease times. They include request transit and processing effects, so use runner-local monotonic measurements for precise command execution durations. Historical or reused steps may have no observations; do not treat missing times as zero or backfill them from runner timestamps.
High-volume windows disclose when metrics are limited to the latest 10,000 runs per period or 10,000 jobs. Narrow the window or select a workflow for a more focused comparison.
Return to the CI overview.