CI Failure Log Analyzer

CI job log:

Paste, drop, or browse one log. Original line order is retained for evidence references.

Provider:

Auto detect resolves visible log grammar; pin a provider when an excerpt no longer contains its normal markers.

Slow step threshold:

Use 60–300 seconds for many jobs; 0 includes every parsed duration.

sec

Mask secret-like values:

{{ mask_secrets ? 'On — safer for handoff' : 'Off — raw snippets may be sensitive' }}

Pipeline label:

Optional label for filenames and document subtitles; detection stays unchanged.

Extra failure terms:

Separate narrow organization-specific phrases with commas or new lines.

Context lines:

Zero keeps the default handoff concise; add up to four neighbors when context changes the next check.

lines

Maximum signals:

The default exposes the full supported ledger; lower it only for a focused handoff.

rows

Line	Severity	Stage	Failure class	Evidence snippet	Confidence	Provider	Copy
{{ row.line }}	{{ row.severity }}	{{ row.stage }}	{{ row.category }}	{{ row.snippet }}	{{ row.confidence }}	{{ providerEvidence }}

Stage	Failures	Warnings	Slow steps	Top clue	First check	Copy
{{ row.stage }}	{{ row.failures }}	{{ row.warnings }}	{{ row.slow }}	{{ row.top_clue }}	{{ row.action }}

Rank	Failure class	Evidence	Affected stage	Next action	Why it matters	Copy
{{ row.rank }}	{{ row.category }}	{{ row.evidence }}	{{ row.stage }}	{{ row.next_action }}	{{ row.why }}

The last line of a failed continuous integration (CI) job usually confirms the failure rather than explains it. An exit-code footer can follow an earlier compiler diagnostic, failed assertion, registry timeout, missing credential, or exhausted runner. Effective triage moves upward to the first specific clue and keeps that line connected to the command or stage that produced it.

Pipeline stages narrow the search. Checkout failures point toward refs, credentials, or submodules; dependency failures toward lockfiles, registries, caches, and runtime versions; test failures toward the first assertion; and deployment failures toward environment state and rollback readiness. A red job can also result from runner disk, memory, or network trouble even when the application code is sound.

CI failure clues and their limits
Clue	Useful conclusion	Required check
File-level compiler or test diagnostic	A narrow command or target can be reproduced.	Read the first diagnostic and its surrounding command.
Timeout or exit 137	Runtime or resource pressure deserves attention.	Inspect the active step, runner limits, and recent successful duration.
Permission or authorization message	Credentials or environment gates may be blocking progress.	Verify secret availability, scope, and protected-environment policy.
Final nonzero exit code	The command failed.	Move earlier in the log to find the explanatory line.

One line can match more than one clue, and repeated consequences can outnumber the initiating error. Severity and confidence labels therefore rank text matches; they do not prove root cause, production impact, or reproducibility. Compare the suspected step with a recent successful run and rerun the smallest relevant command when possible.

Short excerpts save time but can remove stage markers or the first diagnostic. Whole logs provide chronology but may contain irrelevant noise and sensitive values. Retain enough context to identify the active command without sharing unrelated output.

Secret masking reduces accidental disclosure; it is not a security guarantee. CI logs may contain private paths, customer identifiers, proprietary source fragments, or token formats that no pattern recognizes. Review every excerpt before adding it to a ticket, chat, or public issue.

How to Use This Tool:

Keep the failed command, its first diagnostic, and nearby stage marker in one excerpt so the ranked evidence retains useful chronology.

Choose Auto detect for a normal provider log, or pin GitHub Actions, GitLab CI, CircleCI, Jenkins, or generic shell behavior when the excerpt lacks distinctive markers.
Paste the CI job log or load one LOG or TXT file up to 500 KB. Text is limited to 500,000 characters and original line order is retained.
Keep Mask secret-like values enabled for handoff. Add 0 to 4 context lines when a matched clue needs its command nearby, and set the maximum visible signals from 5 to 80.
Set the Slow step threshold from 0 to 86,400 seconds. A parsed duration equal to the threshold is included. Add narrow extra failure terms only for stable organization-specific phrases.
Review the first specific high-confidence clue in Failure evidence, then confirm its stage and follow the matching next check in the triage playbook.

Interpreting Results:

Critical, Failure, Warning, and Slow are rule priorities. Critical patterns include memory exhaustion, timeout, credential trouble, and runner failure; the label does not establish business impact or confirm the cause.

Prefer an early assertion, compiler message, permission denial, or resource clue over a later command footer.
Several matches in one stage show concentrated evidence, not several independent root causes.
Confidence reflects how specific a text pattern is. Even a high-confidence clue needs the raw command and current environment checked.
The maximum-signal setting limits visible evidence. Failure, warning, and slow totals still reflect all detected signals.
An unclassified stage or no recognized clue means the available grammar was insufficient; it does not mean the job passed.

When no useful clue appears, return to the provider's raw job view, find the failed step, and widen the excerpt before adding broad custom terms.

Technical Details:

CI-log triage is a deterministic text transformation followed by ordered rules. The same normalized log and settings produce the same provider choice, stage assignments, signal order, and playbook rows. No probability of failure is calculated.

Transformation Core

Terminal color sequences are removed, line endings are normalized, trailing spaces are trimmed, and line order is preserved.
An explicitly chosen provider is retained. Automatic detection counts recognizable provider markers and falls back to generic shell behavior when none are found.
Group markers and command lines establish stage boundaries. Otherwise, common checkout, dependency, build, test, lint, container, artifact, deployment, and runner terms infer the active stage.
Each line is tested against bounded failure categories and optional custom terms. Lines saying that zero failures occurred, all tests passed, or exit code 0 do not create ordinary failure signals.
Signals are ranked by severity first, then original line number, then category. The visible evidence is capped by the chosen maximum.
Signals are aggregated separately by stage for the ledger and by category for up to eight ranked playbook actions.

Rule Core

CI failure triage severity rules
Priority	Matched classes	Ordering value
Critical	Memory or exit 137, timeout or cancellation, credential or permission trouble, and runner infrastructure failure	4
Failure	Test, compile, dependency, network, artifact, lint, deployment, command-exit, or custom-term matches	3
Warning	Warning and deprecation patterns	2
Slow	A recognized duration greater than or equal to the configured threshold	1

The overall result is Critical if any critical signal exists; otherwise it becomes Failure, Warning, Slow, or Info in that order. Stage summaries choose the highest-severity clue and break ties with the earliest line. Playbook categories are ordered mainly by severity and then by the number of matching signals.

Duration and masking behavior

Durations are recognized from named values such as duration, elapsed, runtime, took, or finished in, including milliseconds, seconds, minutes, and clock-like forms. They are converted to seconds before the inclusive threshold check. Masking replaces familiar password, token, authorization, API-key, access-key, GitHub-token, and three-part token shapes in evidence snippets and attached context. It does not alter the log kept in the input editor.

Mechanism Walkthrough

Suppose a test stage contains an assertion mismatch, a 102-second duration, and a final exit-code line. With a 60-second threshold, the assertion becomes a high-confidence Failure signal, the duration becomes Slow because 102 is greater than or equal to 60, and the footer becomes a lower-information command failure. Ranking places the failure clues before the slow clue, while line references preserve where each appeared.

Privacy Notes:

Logs and local files are analyzed in the current browser tab rather than uploaded. Masking is best effort and covers only known text shapes; disabling it exposes raw evidence snippets and context. Remove sensitive data before analysis when possible, review every generated row before sharing it, and consult the original provider log because the analyzer neither reruns the job nor verifies the environment.

References:

Using workflow run logs, GitHub Docs.
CI/CD job logs, GitLab Docs.
Jobs and steps, CircleCI Docs.
Running Pipelines, Jenkins Documentation.