FREE, NO-FORM CHECKLIST
Separate a GitLab CI queue delay from a job failure.
Use this first pass to gather the right evidence before changing pipeline rules or runner settings. A matching runner tag alone does not prove that a runner is online or has available capacity.
1. Identify the exact run
- Record project, pipeline ID, commit SHA, branch or merge-request context, and approximate time.
- Separate pending, running, failed, canceled, skipped, and manual jobs.
- Compare with a recent successful run on the same relevant ref, if one exists.
2. Measure queue and execution separately
- Note job creation, start, and finish times.
- A wait before a runner starts is different from a slow script after the job starts.
- Check eligible runner assignment, tags, protected-ref rules, scope, and concurrency. Tags are not capacity proof.
- Do not retry or cancel a production job just to collect evidence.
3. Review pipeline rules
- Compare branch, merge-request, tag, schedule, and API-trigger contexts.
- Review workflow and job rules for duplicate pipelines or missing required jobs.
- Confirm skipped jobs are intentionally optional in this context; skipped is not passed.
4. Share evidence safely
- Start with job status, failure reason, timestamps, runner ID, and a short redacted error category.
- Remove tokens, credentials, hostnames, IPs, personal data, environment values, and private source from any excerpt.
- Never submit raw logs, secret values, or production data through a public form.
5. Set a baseline before one reversible change
Choose one measure—such as queue duration, repeat failures, duplicate pipelines, or time to identify a cause. Record its window and source. If no reliable baseline exists, write “unknown”; do not estimate savings.
Agree the desired behavior, acceptance checks, access path, and rollback before changing CI. Validate configuration with GitLab CI Lint or simulation where supported. Use a separate branch and Draft MR or a reviewed patch. Keep merge and deployment under the project owner's control.
6. Verify and close
- Run the agreed checks in the intended branch or merge-request context.
- Report what passed, failed, was skipped, or remained unverified.
- Compare against the baseline and close temporary access after the agreed review.