Synthetic logs · real engine output
An example comparison
Two invented logs of an integration-test job, compared by CI Log Diff 1.0.0-rc.1 when this page was built. The logs are synthetic; the result is exactly what the app shows for them.
The result
34 lines against 35 lines, timestamps ignored. Status findings: 7 changed blocks, 2 error candidates, 23 equal lines, complete coverage.
| Block | Kind | Known good | Failed run | Flag |
|---|---|---|---|---|
change-001 | Changed | line 2 | line 2 | — |
change-002 | Added in failed run | after line 10 | line 11 | — |
change-003 | Changed | line 15 | line 16 | — |
change-004 | Changed | line 18 | line 19 | — |
change-005 | Changed | line 24 | lines 25–27 | Error candidate |
change-006 | Changed | lines 26–28 | lines 29–33 | Error candidate |
change-007 | Removed from failed run | lines 30–33 | after line 34 | — |
How to read it
Every line of the two logs starts with a different timestamp, so a plain diff would mark all 35 lines. With the timestamp prefix ignored, 23 lines are equal and 7 blocks remain.
The first error candidate is change-005:
Known good · line 24
| 24 | 2026-09-15T10:00:24.488Z PASS tests/orders.test.ts (3.1s) |
Failed run · lines 25–27
| 25 | 2026-09-15T14:30:26.801Z FAIL tests/orders.test.ts (3.2s) |
| 26 | 2026-09-15T14:30:26.802Z Error: connect ECONNREFUSED 127.0.0.1:5432 |
| 27 | 2026-09-15T14:30:26.803Z at TCPConnectWrap.afterConnect (node:net:1611:16) |
That is where a reviewer would start. But the more useful lead in this example is a block that is not flagged: the database moved from port 5432 to 5433 while the tests still connect to 5432. No error word appears on that line, so it is a plain change — which is why the app never hides non-candidate changes and says so when the candidate filter is empty.
The example proves nothing about real projects. It is not a benchmark and not a promise of detection accuracy.