Failure fingerprint

Failure fingerprint is a normalized signature extracted from a failed CI job's error output that identifies which problem occurred, so the same underlying failure gets one name and one count across many runs instead of appearing as dozens of unrelated red marks.

How fingerprints are built

The raw material is the failure evidence a pipeline already produces — the tail of the failed job's log, where the terminal error almost always lives. Fingerprinting strips the parts that change on every run (timestamps, run IDs, temp paths, commit hashes, durations) and keeps the parts that identify the cause: the exception type, the failing command, the exit code, the shape of the error message. Two failures that reduce to the same signature are the same problem; grouping by signature turns a wall of failed runs into a short ranked list — fingerprint, occurrence count, affected repositories, and one concrete example line.

Because the signature comes from logs and run metadata, fingerprinting needs no access to source code — the analysis layer never has to read a repository (see how TrimCI enforces that). The honest caveat is granularity: a job-level fingerprint names the recurring error, not the individual test. Per-test flaky detection requires ingesting test-report files from inside the build, which is a different trade-off — the flaky test entry and the TrimCI vs Trunk comparison cover where that line falls.

Why it matters

Triage by fingerprint, not by run. A week with 120 failed runs is unmanageable as a list of runs and trivial as a list of fingerprints — it is usually a handful of distinct problems, and often the top one accounts for most of the count. The grouping answers questions raw run lists cannot:

• Where to start. The fingerprint with the highest count times the longest duration wastes the most compute and engineer time — that ranking, not recency, should set the fix order.
• What kind of problem it is. A fingerprint spanning many repositories at once points at shared infrastructure — a registry outage, a broken runner image — not at any one team's code.
• What retries are hiding. Habitual re-runs turn recurring failures green before anyone reads them; the fingerprint count keeps the recurrence visible and feeds directly into retry tax.

Pre-grouped failures also shorten MTTR, because the first hour of an incident is usually spent discovering that five red pipelines are one problem. Fingerprinting is the backbone of systematic CI pipeline failure analysis.

TrimCI builds error fingerprints from the last 8,000 characters of each failed job's log — logs of successful jobs are never fetched, stored tails are purged after 30 days, and secrets are redacted before anything is displayed. Its reports sort those failures into a fixed set of known error classes — out-of-memory, disk space, network, registry rate limits, test failures, dependency and permission errors, runner timeouts, plus an unclassified bucket — ranked by job count, over the newest log tails in the window rather than every failure. That is a coarser grouping than per-signature clustering.