Question: should netwatch get a way to read the reports its backend stores, and if so, which?
What it is: the backend in the netwatch image (https://git.eeqj.de/sneak/netwatch) stores every report the page sends, as compressed files in the container's /data/reports. Nothing reads them. No page, route or command shows them. The page itself keeps only its last 100 checks, 5 minutes at the default interval.
Example: the network drops for ten minutes in the evening. By morning the page shows only the last 5 minutes. The stored reports cover the outage, but seeing them means copying the files out of the container and decompressing them by hand. Each stored report holds what the page sent: a random browser id and, per host, each check's time, latency and error. The server adds neither the time it received the report nor the sender's address.
Options:
Read route: the backend answers a request such as GET /api/v1/reports?since=... with the stored checks as JSON, for any tool to use. TODO.md lists this as a future step.
History page: a second page in the image that charts each host's stored checks over a chosen time range, built on the read route.
Write-only: as now. The reports are read by hand, or not at all.
Recommendation: Read route. It is the smallest step that makes the stored data usable, and a History page can follow on it later.
**Question**: should netwatch get a way to read the reports its backend stores, and if so, which?
**What it is**: the backend in the netwatch image (https://git.eeqj.de/sneak/netwatch) stores every report the page sends, as compressed files in the container's `/data/reports`. Nothing reads them. No page, route or command shows them. The page itself keeps only its last 100 checks, 5 minutes at the default interval.
**Example**: the network drops for ten minutes in the evening. By morning the page shows only the last 5 minutes. The stored reports cover the outage, but seeing them means copying the files out of the container and decompressing them by hand. Each stored report holds what the page sent: a random browser id and, per host, each check's time, latency and error. The server adds neither the time it received the report nor the sender's address.
**Options**:
- **Read route**: the backend answers a request such as `GET /api/v1/reports?since=...` with the stored checks as JSON, for any tool to use. `TODO.md` lists this as a future step.
- **History page**: a second page in the image that charts each host's stored checks over a chosen time range, built on the read route.
- **Write-only**: as now. The reports are read by hand, or not at all.
**Recommendation**: Read route. It is the smallest step that makes the stored data usable, and a History page can follow on it later.
Found by the acceptance test on https://git.eeqj.de/sneak/netwatch/issues/204.
Model: opus-5-5
sneak
was assigned by clawbot2026-11-11 21:16:49 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Question: should netwatch get a way to read the reports its backend stores, and if so, which?
What it is: the backend in the netwatch image (https://git.eeqj.de/sneak/netwatch) stores every report the page sends, as compressed files in the container's
/data/reports. Nothing reads them. No page, route or command shows them. The page itself keeps only its last 100 checks, 5 minutes at the default interval.Example: the network drops for ten minutes in the evening. By morning the page shows only the last 5 minutes. The stored reports cover the outage, but seeing them means copying the files out of the container and decompressing them by hand. Each stored report holds what the page sent: a random browser id and, per host, each check's time, latency and error. The server adds neither the time it received the report nor the sender's address.
Options:
GET /api/v1/reports?since=...with the stored checks as JSON, for any tool to use.TODO.mdlists this as a future step.Recommendation: Read route. It is the smallest step that makes the stored data usable, and a History page can follow on it later.
Found by the acceptance test on #204.
Model: opus-5-5