Before you start

You need two things:

A GitHub repository with at least one failed Actions run whose logs have not expired. GitHub keeps run logs for 90 days by default.
An API key for a model that supports tool calling. The free Groq tier is enough — see models and keys.

If you have neither to hand, replay a recorded run instead. It is a captured live investigation and exercises the same interface, so the rest of this page still applies.

Run one

1
Open the workspace and name a target
In Investigate, put owner/repo in the repository field. You can paste other things instead and TraceCI will work out what you meant:
all of these are accepted
```
owner/repo
https://github.com/owner/repo
git@github.com:owner/repo.git
https://github.com/owner/repo/tree/break/subtle
https://github.com/owner/repo/actions/runs/1234567890
```
A run URL is the most precise option: it pins the investigation to that exact run instead of to the most recent failure. A tree/ URL carries its branch.
2
Leave the branch blank, or narrow it
Blank means “the most recent failed run on this repository”. Naming a branch is worth doing when several branches are failing at once and you care about one of them.
3
Pick a model and paste your key
Only models known to call tools reliably are offered. Use Check key and model before a real run: it verifies the key and that the model actually emits a tool call. A key that is valid on a model which cannot call tools produces a fluent, confident, entirely wrong answer with no error anywhere — the single worst failure mode in this system, and the only one you cannot see from the result.
4
Start it and watch the trace
The left column fills in as the run proceeds. Rows appear because the agent decided to do something, not because a timer advanced — a row saying Opened app/auth.py means the agent read that file.
5
Read the result from the evidence up
When the diagnosis appears, read the evidence first and the root cause second. In that order you are checking a claim. In the other order you are being persuaded.

What you should expect to see

A typical run takes 15 to 45 seconds. The first ten to fifteen of those are spent before the agent does anything: listing runs, listing jobs, downloading and unzipping a multi-megabyte log archive, resolving the last green commit and fetching the comparison. The trace starts moving immediately so you can tell the difference between working and hung.

Tool-call counts vary by failure type, and a low count is not a worse answer. A dependency failure where the resolver already printed the conflict should use zero tool calls; a subtle type regression usually needs one file read. A run that burns all six calls is usually a run that is lost — see reading an investigation.

Nothing is written to your repository

There is no code path in TraceCI that commits, comments, opens a pull request or re-runs a job. Everything it touches on GitHub is a read.

After the run

Diagnosed runs get a thread id. Opening the full record shows the exact log window and diff the agent was given — the fastest way to check whether it was working from the right inputs.
Every run this browser starts is listed under Investigations, including failures and runs you stopped.
Your key is not part of any of that. It is not in the record, not in the checkpoint and not in the id.

Failure context

What the agent is given before it decides anything.

Reading an investigation

How to tell a strong result from a plausible one.