Current
Generation Pipeline Performance
What timing diagnostics Doxa records for generations and where you can and cannot see them
Overview
Each documentation generation for a project records timing diagnostics. The Doxa team uses these diagnostics to operate the generation pipeline and to find slow steps. They are separate from the progress updates shown for your project, so you will not see them in the Generations page log or in the generation event stream.
To follow a generation as a project owner, use the Generations page in the dashboard. See Generations and Doxabot Instructions for how to start a generation and read its progress and history.
What is recorded
For each analysis, structure, and write stage of a generation, the pipeline records one performance summary. A summary is recorded even when a model request for that stage fails. The summary covers:
| Measurement | What it describes |
|---|---|
| Stage wall time | Total elapsed time for the stage |
| Repository preparation time | Time spent preparing the connected repository |
| Model, tool, and validation calls | How many calls ran and how long they took |
| Busy time | Time the stage was actively working, with overlapping work counted once |
| Peak concurrency | The highest number of model, tool, or validation calls running at the same time |
| Page writing mode | Pages written from preassembled repository evidence, and pages that fell back to the agentic writer |
| Slowest model call | The longest single model request in the stage |
| Unattributed time | Stage time not explained by model, tool, or validation work |
Reading the timing figures
Category totals overlap. A tool call can contain the validation run it triggers, and concurrent calls add up separately. Do not add the categories together, and do not compare their sum with wall time.
To judge how much of a stage was spent working, compare busy time with wall time. Busy time counts each interval of work once, so it is the only figure that fits inside wall time.
Where the summaries go
Performance summaries are written as structured log lines, not to your project. Hosted runs keep them in the pipeline's container logs. Local and synthetic runs also write them to a file. Doxa operators can use these records to compare runs.
No action needed:
Performance recording is automatic. You do not configure it, and no setting in the dashboard turns it on or off.
What this means for your project
A failed log write is reported by the pipeline but never fails a generation. It also never hides an error from a stage.
Telemetry does not change the pages a generation writes or how a failed generation is reported.
If a generation fails or stalls, check its status and history on the Generations page first. Use the generation events to see what was recorded for that run.
For the other telemetry surface, read Generation Observability.