Repository navigation
Soundcheck History
Every snapshot, run and comparison adds a line to .soundcheck/history.jsonl. rhythm soundcheck history shows them as a table with the site's median LCP (or TBT or TTFB) and its trend, so you can see a site getting slower over months, not only since the last snapshot.
rhythm soundcheck historyWhen Kind Name Pages Errors Warnings Verdict LCP (median)
2026-10-25 21:52 snapshot before-update 4 0 1 warnings 146 ms
2026-10-25 21:52 comparison before-update 4 1 4 broke 24 ms
LCP █▁ 146 ms → 24 ms (-84%)
| Column | Means |
|---|---|
| When | when the run started, local time |
| Kind |
snapshot, run or comparison
|
| Name | the snapshot's name; for a comparison, the snapshot it compared with |
| Errors, Warnings | the run's issues by level |
| Verdict |
broke, changed or clean for a comparison; errors, warnings or clean otherwise |
| LCP (median) | the median over the pages that loaded |
The last line is the trend: a sparkline of the runs shown, then the first and last value and the change. Under --plain the sparkline is left out and the arrow is text:
LCP 146 ms to 24 ms (-84%)
| Flag | Description |
|---|---|
--metric lcp|tbt|ttfb |
The timing to show (default lcp). |
--page <path> |
That page's timing instead of the site's median. The history keeps the first 50 pages of each run. |
--backfill |
Add the snapshots and runs still in .soundcheck that the history doesn't have. The first history does this by itself and says on stderr Added 2 past results still in .soundcheck to the history. |
--plain, --no-color
|
As for every command. |
rhythm soundcheck: metric "cls": want lcp, tbt or ttfb
With no entries: No history yet: it grows with every snapshot, run and comparison.
- The HTML report shows the site's LCP trend under the stats once the history has two or more runs of the site: a sparkline and a line such as
LCP 1.4 s to 2.1 s over the last 3 runs(the last 12 runs). - The fleet page draws each site's trend in its LCP column. See Fleet and client reports.
Interrupted runs aren't added. A write that fails prints rhythm soundcheck: history: <why> and the command goes on. Each line is JSON (schema rhythm-soundcheck/history/v1) with the counts, the verdict, the medians and the first 50 pages' timings, so scripts can read it too. The file is in .soundcheck/ but, unlike snapshots and runs, isn't excluded from git; add it to .gitignore if you don't want to commit it.
← Fleet and client reports · Home · Import from BackstopJS and Lost Pixel →
rhythm · Useful ideas. Working systems. · Check only sites you own or have permission to test. Keep staging sealed (responsible use) · This wiki is published from wiki/ in the rhythm repository; suggest changes there with a pull request.
Get started
rhythm in depth
Tuner
- Overview
- Your first scan
- Reading results
- Choosing checks
- Requests and politeness
- Output and reports
- Batch scans
- Local scans
- Integrity and malware
- Changes and notifications
Tuner in depth
- Known vulnerabilities
- PHP advisories
- CI and code scanning
- GitHub Action
- Config file
- Watch and serve
- Writing checks
- Check packs
- Finding reference
- CLI reference
- Coming from Wordfence CLI or WPScan
- FAQ and troubleshooting
Soundcheck
- Overview
- Your first check
- Reading results
- Review and accept
- Discovery
- Page health
- Visual changes
- Interactions
- Forms and flows
- Cache
- Speed
- Accessibility and SEO
Soundcheck in depth
- CI
- CI baselines and PR comments
- Configuration
- Error rules and exec
- WordPress updates
- Fleet and client reports
- History
- Import from BackstopJS and Lost Pixel
- Firefox and WebKit
- CLI reference
- FAQ and troubleshooting
- Benchmark
Echo
- Overview
- Your first run
- Connectors
- Sealing staging
- Echo Inbox
- Messages and checks
- Checks and rules
- Attachments
- Actions and compare
- With Soundcheck
- Replay
- Deliverability
Echo in depth
- Docker and DDEV
- Agency hub and reports
- Schedule
- MCP server
- Conformance kit
- CI
- Configuration
- API
- CLI reference
- FAQ and troubleshooting
- Benchmark
Project