CI/CD Failure Explorer
Paste CI logs from several runs: root cause per run, grouped signatures, top causes and fixes.
Try an example: Eight runs across GitHub Actions, GitLab and Jenkins
How it works
Paste or upload logs of several GitHub Actions, GitLab CI or Jenkins runs (separated by "=== run: name ===" lines). Each run is classified by a documented pattern catalogue — test assertions (with test names), compile/type errors, dependency resolution, network/registry timeouts, OOM/exit 137, disk full, timeouts, lint, flaky retries, missing secrets/permissions — and runs are grouped by normalised error signature with counts per branch and day.
- Runs are split at lines "=== run: <name> ===" (header metadata branch=, date=, status= is honoured). ANSI colours, GitHub timestamp prefixes and GitLab section markers are stripped.
- Platform is detected from runner markers (##[group]/##[error], "Running with gitlab-runner", "[Pipeline]"/"Finished: …"). Status comes from the header, then from terminal markers (Process completed with exit code, ERROR: Job failed, Finished: FAILURE/SUCCESS).
- Every line is matched against a catalogue of documented error markers per cause. When several causes appear, the one with the highest causal priority wins: OOM/exit 137 → disk full → timeout → permission/secret → network → dependency → compile → lint → test → flaky → cancelled (e.g. a test crash after an OOM kill is reported as OOM).
- The first matching line is the evidence; its normalised form (paths, SHAs, UUIDs, timestamps, IPs, line numbers and durations replaced by placeholders) is the signature used to group runs. Test failures are grouped by the sorted names of the failing tests.
- Failing test names are extracted from jest/vitest (●/×), pytest (FAILED a::b), go test (--- FAIL), Maven Surefire ([ERROR] Class.method), Gradle (> … FAILED), TAP/node:test (not ok) and RSpec (rspec ./spec …).
- Flaky suspects: tests that fail in some runs of a job but other runs of the same job (name without #number) pass, and passing runs that contain retry markers.
- Unclassified failures are labelled with the closest match from the Error Message Translator pattern database when possible.
Sources
- GitHub Actions: workflow commands (::error, groups) (GitHub Docs)
- GitHub Actions workflow syntax: jobs.<job_id>.timeout-minutes (default 360) (GitHub Docs)
- GitLab CI/CD YAML reference: timeout, retry:when (GitLab Docs)
- Jenkins hudson.model.Result (SUCCESS, UNSTABLE, FAILURE, NOT_BUILT, ABORTED) (Jenkins)
- Bash manual: Exit Status (128+N for fatal signal N; SIGKILL=9 → 137) (GNU)
- Kubernetes: Assign memory resources (OOMKilled when exceeding the limit) (Kubernetes)
- npm config: legacy-peer-deps / ERESOLVE (npm Docs)
For scripts and AI agents
- JSON API:
POST https://cicdfailureexplorer.usefulweb.site/api/v1/calculate(same calculation as this page) - Interface description: OpenAPI 3.1 · AI guide: llms.txt
- MCP server (Streamable HTTP):
https://cicdfailureexplorer.usefulweb.site/mcp· tool namecicd_failure_explorer
Example request
curl -s -X POST https://cicdfailureexplorer.usefulweb.site/api/v1/calculate \
-H 'content-type: application/json' \
-d '{…see OpenAPI examples…}'Related tools
- Error Message Translator – Paste a technical error and get the plain-English cause and troubleshooting steps.
- Cron Job Explorer – Paste a crontab or CronJob YAML: plain-English schedules, DST-exact next runs, herds and overlaps.