Confirm data is being collected
Use this guide to confirm, from the server side, that developer activity has actually arrived — not that a workstation is configured, but that data landed. A configured workstation and captured data are two separate claims, and the portal home page does not distinguish them.
- Deployment: SaaS, On-premises
- Role: Owner, Admin
What the connection tile does not tell you
The connection tile — labeled Integrations in the System health row on Home — shows how many integrations are connected: source control and AI analysis. It reads as a fraction, such as 1/2 connected, and changes when you add or remove a provider.
It answers one question: are the right integration accounts linked? It does not show whether a developer's workstation is tracking, whether any data has been ingested, or whether a specific developer's activity has arrived. Do not use it as evidence that collection is working.
1. Open developer traces
Select Developer Traces from the left sidebar. The page opens on Recent activity, a fleet-wide roster scoped to the date range shown at the top of the page (30 days by default).
Before reading any numbers, check the System Signals panel under Health & Attention, at the top of the page. It lists derived signals — pipeline lag, stalled sessions, clock skew — that explain why a number might look thin. Read it first — a flagged signal means the numbers you are looking at may still be catching up, not necessarily wrong.
2. Find the developer and period
Search for the developer in the Active Developers roster. Each row shows their session counts (IDE and agent, separately), commit count, active branch count, and a status pill that reflects how recently they were active.
If the developer is not listed, either no activity arrived for them in the current date range, or the period you are checking falls outside it. In that case, adjust the date range at the top of the page to cover the period in question, then check the roster again before drawing any conclusion.
3. Check the counts and coverage
Select Trace on the developer's row to open their trace. This view shows their work-branch cards and runtime sessions, together with an activity-stream summary that shows how much was captured for the period.
Check the following for the period in question:
- Runtime sessions — IDE and agent sessions, counted together in this summary; the work-branch cards below break sessions out per branch. An IDE-only developer legitimately has 0 agent sessions; that is not a gap.
- Commit count — commits attributed to this developer in the period.
- Branches active — branches with activity in the period.
- Total time, cost, lines changed, AI prompts — the honesty conventions under How to read the numbers apply: a genuine
0is not a missing measurement. A work branch's own detail view breaks capture down further per branch — see Validate data with developer traces.
If expected activity is missing, work through the following sections before escalating.
How to read the numbers
The product follows strict honesty conventions. Read these before treating any value as a fault:
| What you see | What it means |
|---|---|
0 | A measured zero — the tracker ran and found nothing for this cell. |
| A blank | Not captured — no measurement exists at all. |
| An empty list | Measured, and none found — the list is real; it is just empty. |
| Unavailable on an analysis tile | The AI review has not run yet — the value is withheld, not zero. |
The distinction between a blank and a zero is the most important one. A zero means data arrived and the value happened to be zero. A blank means no data arrived. A blank is the signal that requires follow-up. One further convention applies to attribution: unattributed work is left unattributed, not guessed — see Validate data with developer traces.
Check data quality before investigating
Before assuming a gap is a bug, check the System Signals panel. Each signal names its own cause plainly — read the message rather than assuming a gap is a bug.
Pipeline lag — the ingest, processor, and analysis stages each carry a lag metric. High lag means data is backed up in the pipeline, not missing. Allow processing to clear before treating a thin count as a permanent gap.
Stalled sessions — a session that opened but did not close holds data in an unprocessed state. A stall shows up as a system signal naming how many sessions are affected. The data is not lost; it is waiting for the session to close or time out.
Clock skew — if the developer's machine clock is significantly out of sync with the server, commits and sessions may fall in the wrong time range and appear absent. Skew shows up as a system signal naming how many sessions are affected. Confirm the developer's system clock is accurate before concluding that data is missing.
When to hand back to the developer
Stop checking server-side and ask the developer to run the client-side diagnostics when any of the following are true:
- The developer does not appear in Recent activity and you have confirmed the period and date range are correct.
- All counts are blank rather than zero — this means no data arrived at all, which points to a workstation configuration issue.
- The System Signals panel shows no lag, stall, or skew, yet the data is still absent — the problem is at the source, not in the pipeline.
Ask the developer to run the following:
aitrax setup check
If system — see How setup works — reports as configured, then:
aitrax health
The health command produces an offline diagnostic rollup of the shared tracker lifecycle log. For the full developer-side check, see Verify your installation.
Related
- Validate data with developer traces — the full drill-down from a dashboard number to the underlying commits, sessions, and analysis facts.
- Verify your installation — the developer-side check when server-side evidence points to the workstation.
- No activity appears for a developer — when a single developer is missing from reports.
- Setup reports not configured — when
aitrax setup checkreports a scope as not configured.