You turn a wall of red test output into a prioritized list of distinct root causes with Atlas by running the suite with the bash tool, which truncates at 2000 lines or 50 KB, writes the complete log to a retained file, and tells you the path. You then read the file named in the ...output truncated... header, group the failures by root cause with grep over the saved log rather than by test name, record one todowrite entry per distinct cause with status pending, and fix them one at a time with edit.
How do I triage a failing test suite without drowning in output?
Atlas triages a failing suite by never reading the whole thing raw. The bash tool truncates at 2000 lines or 50 KB, writes the complete log to a retained file, and tells you the path, so triage happens against the whole log through grep rather than against a lossy tail.
A full test suite produces far more output than any model should read. The naive approaches both fail: dumping everything into context burns the window on stack traces you do not need, and reading only the tail loses the first failures, which are usually the causal ones. The Atlas bash tool takes a third path. It truncates the inline output at 2000 lines or 50 KB so context stays usable, and it retains the complete log in a file and reports the path. The full record is available for targeted grep queries, and nothing was thrown away.
What does the Atlas ...output truncated... header mean?
The Atlas bash tool emits an ...output truncated... header when a command exceeds 2000 lines or 50 KB of output, and the header names the file holding the complete log. Reading that file with the read tool is how you see every failure rather than the fraction that fit inline.
The ...output truncated... header is a pointer, not an apology. When the Atlas bash tool cuts a long test run short inline, the header tells you the path of the file where the full log was written. The read tool opens it. During triage, that file is the source of truth: the inline excerpt shows you that the suite is red, and the retained log shows you everything that went red and in what order. Working from the file also means a second and third pass over the same run costs nothing, because the suite does not need to be re-run to look again.
Should I group test failures by test name or by root cause?
Atlas groups test failures by root cause with grep over the saved log, not by test name. Test names cluster by feature area, but 40 failing tests frequently share 3 underlying causes, and a triage list organized by name creates 40 tasks where a list organized by cause creates 3.
The reason a failing suite feels overwhelming is that the failure count is not the problem count. One changed function signature can redden dozens of tests across unrelated files. Atlas triages against the retained log with grep, searching for the recurring error strings, the repeated exception types, and the shared stack frames that reveal which failures are the same failure. Grouping by root cause is what converts a wall of red into a short, actionable list. The output of triage is a small number of distinct causes, each of which is a real piece of work.
How do I track distinct test failure causes in Atlas?
Atlas records 1 todowrite entry per distinct cause, with status pending, so the fixes are tracked instead of forgotten. After grep groups a red suite into its real root causes, the todowrite list becomes the triage output, and each entry survives across turns until the cause is fixed.
Triage is worthless if the conclusions evaporate. Atlas writes them down. Each distinct root cause identified from the retained log becomes a todowrite entry with status pending, which means the list is an explicit ledger of what is broken and what has been dealt with. The list is visible in the Atlas terminal-native TUI, which is rendered with SolidJS through the OpenTUI renderer, so the remaining causes stay on screen while the work proceeds. A cause that is never entered into todowrite is a cause that gets forgotten when the session moves on.
How do I run a slow test suite without Atlas killing it?
Atlas runs a test suite with the bash tool, passing a generous timeout in milliseconds so a slow suite is not killed mid-run. A suite that legitimately takes 5 minutes needs 300000 milliseconds, and raising that value is the first move before triage can even begin.
A killed test run produces a misleading triage. Half the suite never executed, and the failures you can see may not be the failures that matter. Atlas's bash tool takes an explicit timeout in milliseconds, so the fix is to pass a generous value on the initial full-suite run rather than to interpret a truncated, interrupted result. Getting a complete run is the precondition for everything that follows: the retained log is only authoritative if the suite actually finished, and grouping by root cause over a partial log will systematically miss causes that live in the tests that never ran.
Where does the human approve during Atlas test triage?
During Atlas test triage the human approval points are the bash commands and the diffs. Every Atlas tool call is permission-gated against 3 rule types, allow, ask, and deny, before it runs, and Atlas computes a unified diff for every file edit and surfaces it for approval before writing.
Triage itself is a reading exercise: bash runs the suite, read opens the retained log, and grep groups the failures. Those are permission-gated tool calls, so a repository can auto-allow its own test command while still prompting on anything unexpected. The approval that matters comes when the fixes land. Atlas fixes the causes one at a time with the edit tool, re-running only the affected tests via bash between changes, and each edit arrives as a unified diff you approve before it is written. Fixing one cause at a time, with a targeted re-run in between, keeps the todowrite list honest.
Step by step
- 01Run the suite with the bash tool, passing a generous timeout in milliseconds so a slow suite is not killed mid-run and the triage is based on a complete result.
- 02If the output was truncated, note the ...output truncated... header. The Atlas bash tool truncates at 2000 lines or 50 KB and writes the complete log to a retained file.
- 03Read the file named in the ...output truncated... header with the read tool to see the complete log rather than a lossy tail.
- 04Group the failures by root cause with grep over the saved log, rather than by test name. Many failing tests usually share a small number of causes.
- 05Record one todowrite entry per distinct cause, with status pending, so the fixes are tracked instead of forgotten.
- 06Fix the causes one at a time with the edit tool. Atlas computes a unified diff for every file edit and surfaces it for approval before writing.
- 07Re-run only the affected tests via bash between changes, then run the full suite once the todowrite list is clear.
Frequently asked questions
- how to triage a large number of failing tests
- Group by root cause, not by test name. In Atlas, run the suite with bash, read the complete log from the retained file, grep the log for recurring error strings, and record one todowrite entry per distinct cause with status pending.
- what happens when test output is too long for an AI agent
- Atlas's bash tool truncates the inline output at 2000 lines or 50 KB, writes the complete log to a retained file, and tells you the path, so triage happens against the whole log rather than a lossy tail.
- how do I see the full log after Atlas truncates command output
- Open the file named in the ...output truncated... header with the read tool. The complete log was retained on disk when the bash tool truncated the inline output, so nothing was lost.
- why do my tests fail in dozens but the cause is only a few bugs
- Because one change can redden many tests. Atlas greps the retained log for shared error strings and stack frames to group failures by root cause, turning a long list of red tests into a short list of real problems.
- how do I stop an AI agent from killing my slow test suite
- Pass a generous timeout in milliseconds to the Atlas bash tool. Timeouts are specified in milliseconds, and a complete run is the precondition for triage, since a partial log systematically hides causes in tests that never executed.
- how do I track which test failures I have already fixed
- Use todowrite. Atlas records one entry per distinct root cause with status pending, and the list survives across turns, so a partially triaged suite cannot be mistaken for a fixed one.
- should I fix all failing tests at once
- No. Atlas fixes them one at a time with the edit tool, re-running only the affected tests via bash between changes. Each edit arrives as a unified diff you approve before it is written.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Run the RSpec Test Suite and Triage Failures in Ruby on Rails with Atlas in 2026
Atlas helps Ruby on Rails developers in 2026 efficiently triage RSpec test suite failures, turning a wall of red output into a prioritized list of distinct root causes for faster debugging.
Run the test suite and triage the failures in Quarkus with Atlas in 2026
In 2026, Quarkus developers use Atlas to efficiently run JUnit 5 (@QuarkusTest) suites, parse extensive failure logs, and prioritize distinct root causes for rapid resolution.
Run the Test Suite and Triage Failures in Objective-C with Atlas in 2026
In 2026, Objective-C developers use Atlas to efficiently triage XCTest failures. Turn a wall of red output into a prioritized list of distinct root causes, leveraging real toolchain commands.
Run the Test Suite and Triage Failures in Zig with Atlas in 2026
In 2026, Zig developers use Atlas to efficiently run `zig build test` suites and triage failures. Transform a wall of red test output into a prioritized list of distinct root causes, leveraging Atlas's terminal-native
Run the test suite and triage the failures in Lua with Atlas in 2026
Streamline Lua test triage in 2026. Use Atlas to run `busted` suites, group failures by root cause, and prioritize fixes, transforming a wall of red output into actionable tasks for Lua developers.
Run the test suite and triage the failures in Nim with Atlas in 2026
Efficiently run your Nim test suite and triage failures using Atlas in 2026. Turn a wall of red output into a prioritized list of distinct root causes.
Run the pgTAP Test Suite and Triage SQL Failures with Atlas in 2026
SQL developers in 2026 use Atlas to run pgTAP test suites, triage failures with grep, and track fixes with todowrite, turning red output into prioritized tasks.
Run the Test Suite and Triage Failures in React with Atlas in 2026
React developers in 2026 use Atlas to efficiently triage test failures from Vitest with React Testing Library. Turn a wall of red output into a prioritized list of distinct root causes, streamlining your debugging