Problem
When running tests in parallel across multiple threads/workers (common in E2E and integration testing), it's difficult to understand the actual execution timeline from standard test reports. You can see which tests
passed or failed and their individual durations, but you can't answer questions like:
- How well is work distributed across threads? One worker might be overloaded while others are idle.
- Where are the bottlenecks? A single long-running test on one thread can block the entire suite from finishing sooner.
- What was actually running in parallel? Without a visual timeline, you can't see the concurrency pattern.
- Are there scheduling inefficiencies? Gaps between tests on a thread indicate wasted time.
This is especially important for E2E test suites, for informational purposes and helps investigate tests isolation feature
Some time ago we discussed it here https://github.com/orgs/ctrf-io/discussions/26
Proposed Solution
Add a new timeline-report that renders a Mermaid Gantt chart in the GitHub job summary, showing test execution across threads over time.
Each thread/worker gets a row (section). Tests are displayed as horizontal bars on a shared time axis. Colors indicate status:
- Green — passed
- Red — failed
Skipped/pending tests are excluded from the chart (they didn't execute) but shown in a collapsible details table below with precise timestamps and durations.
Key features
- Groups tests by threadId (falls back to filePath if no thread info, or a single "Tests" section)
- Mermaid Gantt chart — renders natively in GitHub summaries, no external dependencies
- Collapsible details table — shows thread, test name, status, start/stop times (HH:mm:ss.SSS), and duration
- Theme-safe — uses explicit Mermaid base theme with white background and black text for consistent rendering across GitHub light and dark modes
- Sanitizes test names — handles colons, semicolons, and other Mermaid syntax characters
Usage
- uses: ctrf-io/github-test-reporter@v1
with:
report-path: 'ctrf-report.json'
timeline-report: true
CLI:
npx github-actions-ctrf timeline --file ctrf-report.json
Data requirements
The CTRF report must include start and stop timestamps per test. The threadId field is optional but recommended for meaningful thread grouping. Most test frameworks that support parallel execution can provide these fields.
@Ma11hewThomas Please take a look when you have some time for it.
Maybe you have a different vision of the feature, maybe suggestions on how to do it better. As for me Mermaid Gantt is the best trade-off: zero dependencies, native GitHub rendering, good enough visual fidelity.
Problem
When running tests in parallel across multiple threads/workers (common in E2E and integration testing), it's difficult to understand the actual execution timeline from standard test reports. You can see which tests
passed or failed and their individual durations, but you can't answer questions like:
This is especially important for E2E test suites, for informational purposes and helps investigate tests isolation feature
Some time ago we discussed it here https://github.com/orgs/ctrf-io/discussions/26
Proposed Solution
Add a new timeline-report that renders a Mermaid Gantt chart in the GitHub job summary, showing test execution across threads over time.
Each thread/worker gets a row (section). Tests are displayed as horizontal bars on a shared time axis. Colors indicate status:
Skipped/pending tests are excluded from the chart (they didn't execute) but shown in a collapsible details table below with precise timestamps and durations.
Key features
Usage
CLI:
npx github-actions-ctrf timeline --file ctrf-report.jsonData requirements
The CTRF report must include start and stop timestamps per test. The threadId field is optional but recommended for meaningful thread grouping. Most test frameworks that support parallel execution can provide these fields.
@Ma11hewThomas Please take a look when you have some time for it.
Maybe you have a different vision of the feature, maybe suggestions on how to do it better. As for me Mermaid Gantt is the best trade-off: zero dependencies, native GitHub rendering, good enough visual fidelity.