Footer says what a latency figure is (closes #208)

The old line said every check is a GET and that CORS may affect
figures; the S3 targets use HEAD and a no-cors check counts any answer.

Model: opus-5-5

.gitea/workflows/check.yml

@@ -7,8 +7,6 @@ concurrency:
 jobs:
     check:
         runs-on: ubuntu-latest
-        # Free the shared runner from a hung build.
-        timeout-minutes: 20
         steps:
             # actions/checkout v4.2.2, 2026-02-22
             - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
@@ -17,4 +15,7 @@ jobs:
                   persist-credentials: false
                   # All history and tags, so git describe finds the version tag.
                   fetch-depth: 0
+            # Free the shared runner from a hung build. The limit is on the
+            # step because the runner ignores a job's timeout-minutes.
             - run: script/cibuild
+              timeout-minutes: 20

Dockerfile

@@ -62,9 +62,9 @@ WORKDIR /app
 COPY package.json yarn.lock ./
 RUN yarn install --frozen-lockfile
 COPY . .
-RUN NODE_OPTIONS=--test-reporter=dot timeout 90 yarn --silent run test || \
+RUN NODE_OPTIONS=--test-reporter=dot yarn --silent run test || \
     { echo "--- Rerunning with every test listed for details ---"; \
-      NODE_OPTIONS=--test-reporter=spec timeout 90 yarn --silent run test; \
+      NODE_OPTIONS=--test-reporter=spec yarn --silent run test; \
       exit 1; }
 
 # Test phase: the backend's tests with the race detector and coverage,

README.md

@@ -1,8 +1,17 @@
-NetWatch is an MIT-licensed JavaScript single-page application by
-[@sneak](https://sneak.berlin) that provides real-time network latency
-monitoring to common internet hosts, displayed with color-coded figures and
-sparkline graphs, served from a static bucket or from its Docker image, where a
-small Go backend stores the measurements the page reports.
+NetWatch is an MIT-licensed single-page web application by
+[@sneak](https://sneak.berlin) that shows the latency from your browser to 26
+well-known internet hosts. The page is JavaScript and does all its measuring in
+the browser. A small Go backend, `netwatch-server`, stores the measurements the
+page reports. The page and the backend ship together in one Docker image.
+
+## Rationale
+
+When a network misbehaves, it helps to see at a glance which hosts answer and
+how fast. NetWatch is one page with a latency figure and a small graph for each
+host, refreshed every few seconds. The page measures from the browser, so it
+shows the path your own traffic takes. It can be served from any static file
+host. The backend only stores what the page reports. Without it, the page works
+the same and nothing is stored.
 
 ## Getting Started
 
@@ -10,10 +19,10 @@ small Go backend stores the measurements the page reports.
 # Install the dependencies and the git pre-commit hook
 make setup
 
-# Run the page on the Vite dev server
+# Serve the page from the Vite dev server
 make dev
 
-# Build netwatch-server and run it on port 8080
+# Build the page and netwatch-server, then run the server on port 8080
 make run
 
 # Run the tests, both linters and the format check
@@ -22,582 +31,422 @@ make check
 # Build the page into dist/ and netwatch-server into the repo root
 make build
 
-# Build the image and run it
+# Build the Docker image and run it
 make docker
 docker run -p 8080:8080 netwatch
 ```
 
-`make check` and `make docker` need Docker. `make dev` passes `/api` to
-`http://127.0.0.1:8080`, where `make run` starts `netwatch-server` with its
-defaults, so the reports the page posts are stored in `data/reports`.
+`make check` and `make docker` need Docker. `make run` starts `netwatch-server`
+on port 8080 with its defaults, so the page's reports are stored in
+`data/reports`. `make dev` passes the page's `/api` requests there.
 
-## Entrypoints
+## The page
 
-This repository adheres to the
-[Scripts to Rule Them All](https://github.com/github/scripts-to-rule-them-all)
-standard: normalized scripts in `script/` are the entrypoints for the
-development workflow, and the Makefile targets are thin shims that call them.
-The scripts cover both the frontend and the Go backend, so `make check` fails if
-either one is broken. We provide:
+The page shows one row per host: the host's name, its URL, its latest latency in
+milliseconds and a graph of its last 100 checks. Below the figure are the
+minimum, median, average and maximum of the host's answers in that history, or
+`timeout` or `unreachable` after a failed check. A round of checks runs every 3
+seconds by default. The header shows the interval, the history's span, and
+whether the page is running or paused.
 
-- `script/bootstrap` — install all dependencies (the pinned node via nvm unless
-  the `node` on `PATH` has the pinned major version and is new enough for the
-  frontend's dependencies, yarn `YARN_VERSION` via corepack, or npm where there
-  is no corepack, unless the `yarn` on `PATH` is exactly that version,
-  `yarn install --frozen-lockfile`, Go `GO_VERSION` unless the `go` on `PATH` is
-  exactly that version, and the Go modules), linking what it installs itself
-  into `~/.local/bin`, which has to be on `PATH`. It installs no Go linter and
-  not Docker: `make test` and `make lint` run in Docker
-- `script/setup` — make a fresh clone ready for development: bootstrap plus the
-  git pre-commit hook
-- `script/dev` — run the Vite dev server, which proxies `/api` to a locally
-  running `netwatch-server`
-- `script/build` — build the frontend for production into `dist/`, then the
-  static `netwatch-server` binary into the repo root with its version stamped
-  in: `VERSION` from the environment, or when that is unset or empty,
-  `git describe --tags --always --dirty` inside a git checkout, as
-  `script/docker` does, then `dev`
-- `script/run` — build with `script/build`, then run `netwatch-server` with its
-  defaults (see [Settings](#settings))
-- `script/clean` — remove what `script/build` writes
-- `script/projectname` — print the project name (used for the Docker image tag)
-- `script/yarn` — run yarn with the given arguments under the node
-  `script/bootstrap` would use: with `~/.local/bin` first on `PATH`, the first
-  `node` on that `PATH` when it has the pinned major version and is new enough
-  for the frontend's dependencies, and otherwise the pinned node in nvm. Every
-  script that runs yarn on the host runs it through this one, except
-  `script/bootstrap`, which picks its own node and yarn
-- `script/test` — build the `test` phase of `Dockerfile`, writing no image: the
-  frontend's unit tests in its `frontend-test` stage, and the backend's Go tests
-  with the race detector and coverage. The frontend's production build is left
-  to the image build, in the `frontend-build` stage
-- `script/lint` — build the `lint` phase of `Dockerfile`, writing no image:
-  eslint in its `frontend-lint` stage, and golangci-lint over the Go packages
-- `script/fmt` — format all files (writes): prettier over the JavaScript, CSS,
-  HTML and Markdown, then gofmt over `cmd/` and `internal/`. It runs on the
-  host, as `script/fmt-check` does, with `~/.local/bin` put on `PATH`
-- `script/fmt-check` — check formatting (read-only): prettier, then gofmt
-- `script/check` — run test, lint, and fmt-check
-- `script/add-dependency` — add a frontend package, or move one to another
-  version: `make add-dependency PACKAGE=<name>@<version>` runs `yarn add --dev`,
-  which changes `package.json` and `yarn.lock` together, then
-  `yarn install --frozen-lockfile`
-- `script/tidy` — run `go mod tidy`: to add a Go module, import it and run
-  `make tidy`; to move one to another version, edit its `require` line in
-  `go.mod`, then run `make tidy`
-- `script/frontend-test` — run the unit tests in `test/unit/` on the host with
-  Node's built-in test runner, through the `test` script in `package.json`, and
-  if any fails, run them again listing every test, and fail; then the production
-  build. Each test run has a 90-second timeout. `make test` runs the same tests
-  in Docker, without the production build
-- `script/frontend-fmt` — format the JavaScript, CSS, HTML and Markdown with
-  prettier (writes)
-- `script/frontend-fmt-check` — check prettier formatting (read-only)
-- `script/frontend-viewport-test` — responsive-layout verification of the built
-  frontend in a containerised headless Chrome (see
-  [test/viewport/README.md](test/viewport/README.md)). Before the browser
-  starts, it checks that the page, and a path that falls back to it, are served
-  with `Cache-Control: no-cache` and `Content-Security-Policy`. Not part of
-  `script/check`: it takes minutes.
-- `script/docker` — build the image from `Dockerfile`, tagged `netwatch` via
-  `script/projectname`
-- `script/cibuild` — CI entrypoint: runs `script/bootstrap` and `script/check`,
-  then builds the image as `script/docker` does
-- `script/precommit` — run by the git pre-commit hook; runs `script/check`
-- `script/install-precommit` — install the git pre-commit hook
+### Targets
 
-`script/test`, `script/lint`, `script/docker` and `script/cibuild` each pass a
-new `CACHEBUST` value, so every step in `Dockerfile` that lints, tests or
-compiles runs again even when nothing has changed. Docker keeps the system
-packages and the Go modules from earlier builds until the base image, the step
-that installs them, or `go.mod` and `go.sum` change. The `frontend-build` stage
-is the exception: it installs git again on every image build, because it starts
-from the `frontend-test` stage, whose steps run again on every build. Go's build
-cache and golangci-lint's are kept as well, and each reuses a result only when
-everything it was made from is unchanged. Both `go test` runs carry `-count=1`,
-so no test result is reused. The yarn packages are installed again on every
-build.
+The page checks 26 hosts on the internet, the WAN hosts:
 
-## Responsive layout
+- `datavi.be`, pinned to the top at start
+- the Anthropic API and the OpenAI API
+- the AWS Console, the Google Cloud Console and Microsoft Azure
+- Cloudflare, Fastly, Akamai, Google, GitHub and Backblaze B2
+- 8 S3 regional endpoints: Cape Town, London, Bahrain, Tokyo, Singapore, Sydney,
+  Oregon and São Paulo
+- 6 Hetzner speed-test servers: Nuremberg, Falkenstein, Helsinki, Ashburn,
+  Hillsboro and Singapore
 
-The narrow-viewport layout lives in the `max-width: 768px` media block in
-`web/src/styles.css`. It is verified automatically by
-`make frontend-viewport-test`, which drives a digest-pinned headless Chrome
-against the built `dist/` and asserts on computed layout at widths derived from
-that CSS — on every breakpoint it declares and one pixel either side of it, plus
-a 320px floor, a desktop baseline and two landscape sizes. See
-[test/viewport/README.md](test/viewport/README.md) for what it covers and what
-it genuinely cannot.
+Two local targets follow under the heading "Local Network", left out of the
+summary and the health box. `Local CPE` is the cable modem at
+`http://192.168.100.1`. `Local Gateway` is the first of `http://192.168.1.1`,
+`http://192.168.0.1`, `http://192.168.8.1` and `http://10.0.0.1` to answer
+within 1.5 seconds of the page loading; with no answer, it has no row. Browsers
+block a page served from a public address from reaching private addresses. So
+the local targets answer only when the page is served from `localhost` or from a
+private address.
 
-## Rationale
+The host list is written in `web/src/main.js`; there is no setting for it.
 
-When debugging network issues, it's useful to have a persistent at-a-glance view
-of latency and reachability to multiple well-known internet endpoints. NetWatch
-provides this as a single page that does all its measuring in the browser, so it
-can be served from anywhere static files are served. The backend in its Docker
-image only stores the measurements the page reports; without it, the page works
-the same and nothing is stored.
+### What a figure measures
 
-## Design
+A check is a request to the target's URL: `GET`, or `HEAD` for the S3 regions.
+The figure is the time from sending the request until the response headers
+arrive, in milliseconds. Unlike ping, it includes the time the server takes to
+answer. On a new connection it also includes the DNS lookup, the connection
+setup and the TLS handshake. Any answer counts as reachable, an error page
+included. The browser follows redirects, so a target whose home page redirects
+is checked at `/robots.txt` on the same host.
 
-The page's source is in `web/`, the Go backend's in `cmd/` and `internal/`, and
-nginx's configuration in `configs/`.
+A check times out after 80% of the interval: 2.4 seconds at the default. A check
+that answers after that limit counts as a timeout too. A check that fails with a
+network error is recorded as unreachable. The first round after the page loads
+is discarded, as its figures include the connection setup. So is the first round
+after an interval change.
 
-The page is built with Vite and Tailwind CSS v4. Its code is all in
-`web/src/main.js`, with a class-based architecture:
+### Health and summary
 
-- **`CONFIG`**: Configuration object (update interval, timeouts, axis ticks,
-  etc.). The interval menu sets `updateInterval`, the one value the page writes
-  into `CONFIG`; the timeouts, the time the history spans and the x-axis ticks
-  are computed from it
-- **`HostState`**: Per-host state management — history buffer, latency tracking,
-  status transitions
-- **`AppState`**: Top-level state container — WAN hosts, local hosts, pause
-  state, aggregate stats
-- **`SparklineRenderer`**: Canvas 2D sparkline drawing with fixed axes,
-  color-coded line segments, error regions, and DPR-aware scaling
-- **UI functions**: `buildUI()` constructs the DOM, `updateHostRow()` /
-  `updateSummary()` / `updateHealthBox()` handle incremental updates
-- **`tick()`**: Main loop — measures all hosts in parallel, pushing each host's
-  sample and redrawing its row as soon as its check ends, then redraws every
-  row, the summary and the health box once the last check ends. The first round,
-  after loading or an interval change, is discarded. The rows are sorted when
-  the last check ends in round 2, the first one kept, and in rounds 11, 21, 31
-  and so on. When paused, pushes blank markers (no probes, no false outage)
-- **`Reporter`**: Posts collected samples to the backend
+Above the rows, a health box sums up the WAN hosts' latest results. A host
+counts as failed when its last check timed out or found it unreachable.
 
-### Reporting
+- `OFFLINE` (red): more than 10 hosts failed and at most 4 answered
+- `DEGRADED` (orange): otherwise, more than 4 hosts failed
+- `SLOW` (yellow): otherwise, more than 3 hosts took over 1000 ms
+- `HEALTHY` (green): otherwise
 
-Every `reportInterval` (default 60s) the page POSTs a JSON report to the
-same-origin path `/api/v1/reports`: a random per-browser `clientId` kept in
-`localStorage`, `geo` sent as null, and each host's unreported, non-paused
-samples (timestamp, latency, error). A per-host high-water mark makes every
-report a delta, so only new samples are sent; the mark advances only on a
-delivered report, and while paused nothing is sent. Changing the interval clears
-each host's history on the page; the samples in it not yet reported still go in
-the next report. Delivery failure is quiet — one debug-log line per outage,
-never blocking probing. The report-building step is a pure function of host
-state.
+Below it, a summary line covers the WAN hosts only:
 
-A sample in the history that no report has delivered is sent only as long as the
-history holds it, so after a refused or failed report the next report carries
-the samples the history still has. Samples an interval change cleared from the
-history are kept apart, the last 100 per host, until they are delivered. The
-history keeps each host's last 100 rounds: 100 seconds at the 1-second interval,
-200 seconds at 2 seconds, 5 minutes at the default of 3 seconds and 100 minutes
-at 60 seconds. At 1 second, one refused or failed report loses the oldest 20
-seconds of each host's samples, as the next delivered report comes 2 minutes
-after the last. At 2 seconds and longer one loses nothing; samples are lost from
-the third refused report in a row at 2 seconds, from the fifth at 3 seconds, and
-later still at the longer intervals.
+- `Reachable`: how many of the 26 answered their last check
+- `Now`: the minimum, median, average and maximum of their latest figures
+- the history's span, such as `5m`: the minimum and maximum over the whole
+  history
+- `Checks`: the rounds run since the page loaded or the interval changed
 
-No report is sent while the page is paused, but each paused round still adds an
-entry to the history, so each report due during a pause counts as a refused one.
-A pause longer than the history spans loses the samples in the history recorded
-between the last delivered report and the pause: up to a minute's worth for each
-host if the report before the pause was delivered.
+When no WAN host answers, the page checks 4 of them, picked at random, every
+half second. As soon as one answers, a new round starts.
 
-### Backend
+### Rows, colors and controls
 
-`netwatch-server` is a small Go HTTP server that stores the reports the page
-posts. It keeps them in memory and writes them to `DATA_DIR` as zstd-compressed
-files of JSON lines: every minute, whenever 10 MiB are waiting, and when it
-stops. Its routes:
+A figure and its line in the graph take the color of the legend in the footer,
+from green under 50 ms to red from 500 ms up; gray is no answer. The graph's
+axis ends at 1000 ms; a higher latency is drawn at the top, and the figure still
+shows its real value.
 
-- `POST /api/v1/reports` — takes a report, without credentials; each client
-  address may send a limited number a minute, and the report files are capped in
-  size, the oldest deleted first
-- `GET /.well-known/healthcheck` — answers 200 with `"status":"ok"`, the
-  server's version and its uptime; while reports cannot be stored, as the last
-  write of a report file failed, it answers 503 with `"status":"error"` and the
-  same fields (see [Report storage](#report-storage))
-- `GET /metrics` — Prometheus metrics behind basic auth, only when
-  `METRICS_USERNAME` and `METRICS_PASSWORD` are set; each client address may
-  make a limited number of requests to it a minute
+From time to time, the page sorts the WAN rows by their latest latency: fastest
+first, failed last. The pin button at the left of a row keeps the row at the
+top; pinned rows are sorted by name. `datavi.be` is pinned at start.
 
-It is an `fx`-wired Go application: `cmd/netwatch-server/` starts it, and its
-packages are in `internal/`:
+`Pause` stops the checks: the graphs keep scrolling with a gap for each paused
+round, and the figures turn gray. The `Interval` menu sets the time between
+rounds: 1, 2, 3, 5, 10, 15, 30 or 60 seconds. Changing it clears the history and
+starts a new round at once. The `Debug log` checkbox in the footer opens a panel
+with the page's last 1000 log lines.
 
-- **`cli`**: Runs `netwatch-server` from its command line: the `check-cidr` and
-  `prepare-data-dir` subcommands, which `bin/entrypoint.sh` runs before it
-  starts the server, and, given no arguments, the server, with the `fx` wiring.
-  It refuses any other arguments with a usage message and exit code 2.
-- **`config`**: Loads configuration from environment variables and config files
-  via Viper.
-- **`handlers`**: HTTP request handlers for the API (health check, report
-  ingestion).
-- **`reportbuf`**: The in-memory buffer of reports and the files it writes them
-  to.
-- **`server`**: Chi-based HTTP server with middleware wiring and route
-  registration.
-- **`healthcheck`**, **`middleware`**, **`logger`**, **`globals`**: Supporting
-  infrastructure.
+## Reporting
 
-In the image, the `test` phase of `Dockerfile` tests it, the `builder` stage
-builds it, and `bin/entrypoint.sh` runs it as user `netwatch` on
-`127.0.0.1:8081`, behind nginx (see [Deployment](#deployment)). Outside the
-image, `make run` builds it and runs it on port 8080.
+Every 60 seconds the page posts its undelivered samples as a report to
+`/api/v1/reports` on the origin it was served from. The report is JSON with four
+fields:
 
-#### Settings
+- `clientId`: a random id, made once per browser and kept in `localStorage`, or
+  once per session when the browser has no usable storage
+- `geo`: always `null`
+- `hosts`: one entry per host with new samples: its `name`, `url` and `status`,
+  and `history`, its samples. A sample has the check's time `t` in Unix
+  milliseconds, its `latency` (`null` for a failed check) and its `error`
+  (`"timeout"`, `"unreachable"` or `null`).
+- `timestamp`: the time of the report
 
-| Variable               | Default              | Description                                                                                              |
-| ---------------------- | -------------------- | -------------------------------------------------------------------------------------------------------- |
-| `BIND_ADDRESS`         | empty                | IP address to listen on; empty listens on every interface                                                |
-| `PORT`                 | `8080`               | HTTP listen port                                                                                         |
-| `DATA_DIR`             | `./data/reports`     | Directory for compressed reports                                                                         |
-| `DATA_DIR_MAX_BYTES`   | `1073741824` (1 GiB) | Most bytes of report files kept in `DATA_DIR`, oldest deleted first; see [Report limits](#report-limits) |
-| `DEBUG`                | empty                | Debug logging; any non-empty value, `false` and `0` included, turns it on                                |
-| `TRUSTED_PROXIES`      | RFC 1918 ranges      | Comma-separated CIDRs whose `X-Forwarded-For` / `X-Real-IP` headers are trusted for client IP resolution |
-| `REPORTS_PER_MINUTE`   | `60`                 | Reports each client address may send a minute; see [Report limits](#report-limits)                       |
-| `CORS_ALLOWED_ORIGINS` | empty                | Comma-separated origins whose pages may call the API; see [CORS](#cors)                                  |
-| `METRICS_USERNAME`     | empty                | Basic auth user name for `/metrics`; see [Metrics](#metrics)                                             |
-| `METRICS_PASSWORD`     | empty                | Basic auth password for `/metrics`; see [Metrics](#metrics)                                              |
-| `SENTRY_DSN`           | empty                | DSN of the Sentry project to send errors to; see [Sentry](#sentry)                                       |
+Each report carries only the samples no earlier report has delivered. A sample
+waits as long as the history holds it: the last 100 rounds of each host. An
+interval change clears the history. The cleared samples are kept, the last 100
+of each host, until a report delivers them. Nothing is sent while the page is
+paused. A report with no answer after 30 seconds is abandoned, and its samples
+go in the next one. So a server that stored them but answered late gets them
+twice.
 
-`TRUSTED_PROXIES` defaults to `10.0.0.0/8,172.16.0.0/12,192.168.0.0/16`. A list
-replaces the default; set and empty, the server trusts no proxy. Loopback is not
-in the default, so a reverse proxy on the same host has to be named, as in
-`TRUSTED_PROXIES=127.0.0.1/32`. A request whose direct peer is outside this set
-has its forwarded headers ignored, and the direct peer is logged and
-rate-limited instead. From a direct peer inside the set, the client address is
-the right-most `X-Forwarded-For` entry that is not in the set: each proxy
-appends the address it took the request from, so the entries further left were
-written by the client and are not used. An entry written as an address with a
-port, such as `198.51.100.7:5000` or `[2001:db8::1]:443`, is read as that
-address. If the search from the right finds only addresses in the set, or meets
-an entry that is not an address at all, such as `unknown`, the direct peer is
-used. `X-Real-IP` is read only when `X-Forwarded-For` is missing or empty. The
-container image does not use this default; see [Deployment](#deployment).
-
-A variable set to a value the server cannot use, such as `PORT=abc` or a
-`BIND_ADDRESS` that is not an IP address, stops it from starting, with an error
-naming the variable. An empty variable counts as unset, except
-`TRUSTED_PROXIES`. No value of `DEBUG` stops the start.
-
-#### Report storage
-
-Reports are written as `reports-<timestamp>-<number>.jsonl.zst` files in
-`DATA_DIR`. The timestamp is in UTC to the millisecond, so the names sort by
-time. The number starts at 1 when the server starts and goes up by one for each
-file the server starts to write, so two files written in the same millisecond
-still get different names. A failed write uses up its number and leaves a gap in
-the numbers: its file, if it was created, is removed. The file stays, counted
-toward `DATA_DIR_MAX_BYTES` from the next start, only if removing it fails too.
-Files are created with `O_EXCL` to prevent overwrites.
-
-The reports of a failed write stay in memory, and the next flush, within a
-minute, tries again to write them. The server writes one file at a time, so a
-file holds its reports in the order they arrived, those of a failed write
-included. From the failed write until a write succeeds, `POST /api/v1/reports`
-refuses every report with 500 and keeps nothing of it, and the health check
-answers 503 with `"status":"error"`. The page sends the refused samples again in
-its next report, as long as it still holds them: at the 1-second interval one
-refused report already loses some of those in the history (see
-[Reporting](#reporting)). Reports already answered 200 are lost only if the
-server stops before a write succeeds; the final flush at stop tries them too,
-and if it fails, the process exits non-zero.
-
-#### Report limits
-
-`POST /api/v1/reports` takes reports from anyone who can reach it, without
-credentials, so it is bounded instead. Each refusal below answers with the same
-`{"status":"error"}` body as any other error, except nginx's refusal of a body
-over the limit in the image.
-
-- **JSON only.** A report must be sent with `Content-Type: application/json`,
-  parameters such as `charset` allowed, as the page sends it; any other is
-  refused with 415, and nothing of it is stored. A page on another origin can
-  send a `text/plain` POST, or a form, without a CORS preflight; refusing them
-  keeps any site from making its visitors' browsers store reports (see
-  [CORS](#cors)).
-- **Body limit.** A report body may be at most 1 MiB, the backend's limit for
-  any request. Run on its own, the backend answers 413 before the route to a
-  request that declares a longer body. Without a declared length, the route
-  answers 413 only when the report it reads runs past 1 MiB; nothing after the
-  end of the report is read, so a longer body whose report ends sooner is
-  stored, and one that stops being valid JSON sooner is answered 400. In the
-  image, nginx refuses a body over 1 MiB first, with or without a declared
-  length, as its `client_max_body_size`, which `configs/nginx.conf` does not
-  set, is 1 MiB by default. nginx answers 413 with its own HTML error page, and
-  the backend never sees the request.
-- **Rate limit.** Each client address, resolved through `TRUSTED_PROXIES`, may
-  send `REPORTS_PER_MINUTE` reports a minute; past that it gets 429 with
-  `Retry-After: 60`. The minute slides: reports from the minute before still
-  count, fading out over the current one, so an address is sure never to be
-  refused only while it sends at most half of `REPORTS_PER_MINUTE` in any 60
-  seconds. The page sends one report a minute from each open tab, so the default
-  of 60 refuses nothing from up to 30 tabs behind one address, such as a
-  household or an office sharing it, however their reports bunch up. Report
-  responses also carry `X-RateLimit-Limit`, `X-RateLimit-Remaining` and
-  `X-RateLimit-Reset` headers.
-- **Size cap.** The report files in `DATA_DIR` may total at most
-  `DATA_DIR_MAX_BYTES`, counting the files already there at start. Reports
-  waiting in memory count at their uncompressed size until they are written,
-  those of a failed write included; the part of its file written is removed.
-  When a report would take the total past the cap, the oldest report files are
-  deleted to make room, and each deletion is logged with the file's name and
-  size; a file still being written is never deleted. A report is refused with
-  507, and nothing of it is stored, only when the reports waiting to be written
-  fill the cap on their own, and then no file is deleted. At start, report files
-  past the cap, as after lowering it, are deleted the same way. So the cap is
-  how much of the newest reports is kept: the default of 1 GiB is small enough
-  for any host; set it to the space you can give `DATA_DIR`.
-
-At the defaults, one address may send 60 reports of up to 1 MiB a minute, and a
-report made up to compress badly takes about as much room in the report files as
-its request body, so in about 17 minutes one address can fill the 1 GiB cap with
-its own reports, every report stored before them deleted to make room. Lowering
-`REPORTS_PER_MINUTE` or raising `DATA_DIR_MAX_BYTES` makes that take longer.
-
-#### CORS
-
-The page calls the API from the origin it is served from, so by default the
-server sends no CORS headers, and browsers let no other origin's pages call it.
-To serve the page from elsewhere, list that origin in `CORS_ALLOWED_ORIGINS`
-(for example `https://netwatch.example.com`); pages from a listed origin may
-`GET` and `POST` with a `Content-Type` header. Each entry must be a plain
-origin, `scheme://host` with an optional `:port`, as browsers send it: no path,
-not even a trailing `/`, and no `*`. Any other entry stops the server from
-starting, with an error naming `CORS_ALLOWED_ORIGINS`.
-
-#### Metrics
-
-With both `METRICS_USERNAME` and `METRICS_PASSWORD` set, the server serves
-Prometheus metrics at `GET /metrics` to requests with those as their basic auth
-credentials, and answers any other with 401. For each request that reaches the
-health check or `POST /api/v1/reports`, those the rate limit refuses included,
-the metrics record its duration and response size, labelled with its path,
-method and status; they also count those requests in progress, and include Go's
-runtime and process metrics. No other request is recorded: not those to
-`/metrics` itself, and not those answered before they reach either route, such
-as a CORS preflight, or a request refused with 404 for a path no route has or
-405 for a method its route does not take. Run on its own, the backend also
-answers 413 before the route to a request declaring a body length over the 1 MiB
-limit, which is not recorded. A body over the limit sent without a declared
-length reaches the route and is recorded with the status the route answers,
-which is 413 only when the report it reads runs past the limit: nothing after
-the end of the report is read. In the image neither reaches the backend: nginx
-answers both with 413 itself (see [Report limits](#report-limits)), and nothing
-of them is recorded. Clients can make up any number of paths and methods, and
-each would add labels to the metrics for as long as the server runs.
-
-`/metrics` is rate limited, so that its password cannot be guessed quickly: each
-client address, resolved through `TRUSTED_PROXIES`, may make 60 requests to it a
-minute, whatever their credentials. Past that it gets 429 with
-`Retry-After: 60`, and its credentials are not checked. The minute slides as it
-does for reports (see [Report limits](#report-limits)), so a scraper polling
-every 2 seconds or less often is never refused. This allowance is apart from the
-one for reports.
-
-#### Sentry
-
-With `SENTRY_DSN` set, each panic in a handler is reported to that Sentry
-project under the release `netwatch-server-` followed by the server's version.
-On shutdown the server waits up to 2 seconds for Sentry to finish sending.
-
-### Monitoring targets
-
-- **26 WAN hosts**: datavi.be (pinned at start), Anthropic API, OpenAI API, AWS
-  Console, Google Cloud Console, Microsoft Azure, Cloudflare, Fastly CDN,
-  Akamai, Google, GitHub, B2, 8 S3 regional endpoints (Cape Town, London,
-  Bahrain, Tokyo, Singapore, Sydney, Oregon, São Paulo) and 6 Hetzner speed test
-  servers (Nuremberg, Falkenstein, Helsinki, Ashburn, Hillsboro, Singapore)
-- **Local CPE**: Cable modem at 192.168.100.1 (always monitored)
-- **Local Gateway**: Auto-detected on startup by probing common default gateway
-  addresses (192.168.1.1, 192.168.0.1, 192.168.8.1, 10.0.0.1); first responder
-  wins. Note: modern browsers enforce Private Network Access restrictions that
-  block public-origin pages from reaching RFC1918 addresses, so local targets
-  only work when NetWatch is served from localhost or a private address.
-
-Local hosts are tracked separately from WAN stats.
-
-### Latency measurement
-
-GET requests to each target's URL as written, with `mode: 'no-cors'` and
-`cache: 'no-store'`, timed with `performance.now()`. No query string is added:
-the Hetzner speed-test servers close the connection without an answer when the
-URL has one, and `no-store` keeps the browser's cache out of the measurement.
-Each check times out after 80% of the refresh interval (24 seconds at 30
-seconds) and is then recorded as a timeout, so a round's checks have all
-finished before the next round is due. When no WAN host answers, a recovery
-probe checks 4 WAN hosts, picked at random when it starts, every half second,
-giving up the checks it started half a second before. As soon as one answers, a
-new round starts at once, as it does after an interval change. A round started
-early gives up the last round's checks if they are still waiting, and that round
-records nothing more, so rounds never overlap. The browser chooses between IPv4
-and IPv6 for each target, as for any request; the local targets are IPv4
-addresses.
-
-Each recorded check that fails writes one line to the browser console with
-`console.error`, and the same line to the debug log: the target's name and URL,
-the time, whether it timed out, answered over the time limit or hit a network
-error (with the error the browser gives the page, such as
-`TypeError: Failed to fetch`, which does not say why), and how long the request
-took. A target that answers after failed checks writes one `console.info` line
-with its latency and how many checks in a row had failed.
-
-### Color coding
-
-| Latency     | Color  |
-| ----------- | ------ |
-| < 50ms      | Green  |
-| < 100ms     | Lime   |
-| < 200ms     | Yellow |
-| < 500ms     | Orange |
-| >= 500ms    | Red    |
-| Unreachable | Gray   |
-
-### Output structure
-
-```
-dist/
-├── index.html
-└── assets/
-    ├── index-*.css
-    └── index-*.js
-```
-
-## Features
-
-- A round of checks every 3 seconds by default; the interval menu sets 1, 2, 3,
-  5, 10, 15, 30 or 60 seconds and clears the history
-- Sparklines of each target's last 100 rounds: 300 seconds at 3 seconds
-- The first round after loading or an interval change is discarded, as DNS and
-  TLS setup inflate its latencies
-- Health indicator from the WAN hosts' latest results: OFFLINE (red) when more
-  than 10 fail and at most 4 answer, otherwise DEGRADED (orange) when more than
-  4 fail, otherwise SLOW (yellow) when more than 3 take over 1000ms, otherwise
-  HEALTHY (green)
-- Summary stats across WAN hosts only: how many answered, the min, median,
-  average and max of their latest latencies, the min and max over the whole
-  history, and the number of rounds run (`Checks`)
-- Fixed chart axes: Y-axis 0–1000ms, higher latencies drawn at the top; X-axis
-  the time the history spans
-- Color-coded latency figures and sparkline line segments
-- WAN host rows sorted by latest latency, unreachable last; pinned rows stay on
-  top, in name order
-- Play/pause: pause stops probes but history keeps scrolling (blank gaps, no
-  false outage)
-- Debug log panel, behind a checkbox in the footer, with five levels (error,
-  warning, notice, info, debug) and the last 1000 lines
-- Local and UTC clocks
-- Clickable service URLs
-- A footer link to the commit the page was built from
-- Canvas-based sparkline rendering with devicePixelRatio scaling
-- Zero runtime dependencies: all resources bundled into build artifacts
+A failed delivery is quiet, as on a static file host with no backend: one debug
+log line when deliveries start failing, one when they recover. The checks go on.
 
 ## Deployment
 
-`make build` writes the page to `dist/`, which any static file host (S3, GCS,
-Cloudflare Pages, Vercel, Netlify, GitHub Pages) can serve; with no backend
-there, its reports fail quietly and nothing is stored. Or run the Docker image
-behind a reverse proxy.
+`make docker` builds the image `netwatch` from `Dockerfile`: the whole service
+in one container. nginx serves the page and passes `/api/`,
+`/.well-known/healthcheck` and `/metrics` to `netwatch-server` in the same
+container. The backend listens on `127.0.0.1:8081` only, as user `netwatch` (uid
+1000). `bin/entrypoint.sh` starts both and watches them.
 
-The Docker image, built from `Dockerfile` by `make docker`, is the whole service
-in one container: nginx serves the built frontend and passes `/api/`,
-`/.well-known/healthcheck` and `/metrics` to the Go backend, `netwatch-server`.
-`bin/entrypoint.sh` starts it listening only inside the container, on
-`127.0.0.1:8081`, with `TRUSTED_PROXIES=127.0.0.1/32`, so it takes the client
-address nginx passes on and no other. The image:
+Before the backend starts, `bin/entrypoint.sh` runs two subcommands of
+`netwatch-server`. `check-cidr` checks each `TRUSTED_PROXIES` entry (see
+[Running under upaas](#running-under-upaas)). `prepare-data-dir` creates the
+report directory and gives `/data`, with the directories, regular files and
+symbolic links in it, to user `netwatch`. It changes nothing outside `/data`.
 
-- Listens on port 8080 by default (override with `PORT` env var)
-- Takes the client address from `X-Forwarded-For` only on requests from the
-  reverse proxies named in `TRUSTED_PROXIES`, by default from any address in
-  `10.0.0.0/8`, `172.16.0.0/12` or `192.168.0.0/16`. `bin/entrypoint.sh` checks
-  each entry with `netwatch-server check-cidr`, which parses it as the backend
-  parses its own `TRUSTED_PROXIES`
-- Sends access logs to stdout
-- Sends the page with `Cache-Control: no-cache`, so a browser that keeps a copy
-  checks with the server that it is current before using it again; only the
-  files under `/assets/`, whose names change whenever their contents do, are
-  cached as immutable
-- Sends the security headers `REPO_POLICIES.md` requires on every response, as
-  `configs/security-headers.conf` sets them, in place of the backend's own
-- Stores reports in `DATA_DIR`, `/data/reports` by default, on the `/data`
-  volume. Before the backend starts, the image creates `DATA_DIR` and gives it
-  and `/data` to user `netwatch` (uid 1000), which the backend runs as, with
-  `netwatch-server prepare-data-dir`, which acts on nothing outside `/data`, so
-  a host directory bind-mounted at `/data` ends up owned by uid 1000
-- Writes buffered reports to disk on `docker stop`, and exits non-zero if nginx
-  or the backend exits on its own, so the platform restarts it
+The image also:
 
-## Running under upaas
+- takes the client address from `X-Forwarded-For` only on a request from a proxy
+  named in `TRUSTED_PROXIES`, and passes that one address to the backend. The
+  backend is started with `TRUSTED_PROXIES=127.0.0.1/32`, so it trusts nginx
+  alone.
+- writes nginx's access log and the backend's JSON log to stdout
+- refuses a request body over 1 MiB with nginx's own 413 error page
+- requests `/.well-known/healthcheck` through nginx every 30 seconds, as its
+  `HEALTHCHECK`. The check fails unless both nginx and the backend answer, and
+  while report files cannot be written.
+- on `docker stop`, writes the waiting reports to disk and exits 0, or non-zero
+  if that write fails. If nginx or the backend exits on its own, the other is
+  stopped and the container exits non-zero.
 
-What the [upaas](https://git.eeqj.de/sneak/upaas) app for netwatch needs:
+### Running under upaas
 
-- **Port:** container port `8080`.
-- **Volume:** container path `/data`; the reports are kept in `/data/reports`.
-- **Environment variables:** none is required. An empty one counts as unset,
-  except `TRUSTED_PROXIES`, and one set to a value netwatch cannot use stops the
-  container at start, with the reason in its log.
-    - `PORT`, default `8080`: the container port, from 1 to 65535. `8081` cannot
-      be used: the backend listens on it inside the container
-    - `REPORTS_PER_MINUTE`, default `60`: reports each client address may send a
-      minute
-    - `DATA_DIR_MAX_BYTES`, default `1073741824` (1 GiB): the most room the
-      report files may take; the oldest are deleted to stay under it
-    - `CORS_ALLOWED_ORIGINS`, default empty: other origins whose pages may call
-      the API
-    - `DEBUG`, default empty: debug logging; any non-empty value, `false` and
-      `0` included, turns it on
-    - `DATA_DIR`, default `/data/reports`: the directory the reports are kept
-      in: `/data` or a path below it, with no `.` or `..` part and no extra `/`.
-      The container also stops if the path goes through a symbolic link that
-      leads out of `/data` or is written as a full path
-    - `TRUSTED_PROXIES`, default `10.0.0.0/8,172.16.0.0/12,192.168.0.0/16`: the
-      addresses the reverse proxy in front of the container connects from, as IP
-      addresses or CIDRs separated by commas. nginx takes the client address
-      from `X-Forwarded-For` only on a request from one of them, and the rate
-      limit counts that address. A list replaces the default. Set and empty,
-      `X-Forwarded-For` is ignored and every client behind the proxy shares the
-      proxy's one allowance of `REPORTS_PER_MINUTE`. Any client that connects
-      from one of these addresses can write its own `X-Forwarded-For`, and
-      through a port Docker publishes, every client may connect from the Docker
-      network's gateway, such as `172.17.0.1`, which the default includes; where
-      that matters, name only the addresses nothing but the proxy connects from.
-    - `METRICS_USERNAME` and `METRICS_PASSWORD`, default empty: with both set,
-      the backend records Prometheus metrics of its requests and serves them at
-      `/metrics` on the container port, to requests with this user name and
-      password as their basic auth credentials. With neither set, there are no
-      metrics and `/metrics` is not found. One set without the other, or a user
-      name containing `:`, stops the container
-    - `SENTRY_DSN`, default empty: set to a Sentry project's DSN, the backend
-      sends its errors to that Sentry project: each request whose handling
-      crashes, which still gets a 500 response. A value Sentry does not accept
-      stops the container. Empty, the backend sends nothing to Sentry
-- **Health check:** the image's `HEALTHCHECK` requests
-  `/.well-known/healthcheck` through nginx every 30 seconds, so it fails unless
-  both nginx and the backend answer. It also fails while reports cannot be
-  stored, as when the volume is full or `DATA_DIR` cannot be written: the health
-  check answers 503 from a failed write of a report file until a write succeeds,
-  and the backend tries the write again every minute. Three failed checks in a
-  row make the container `unhealthy`, and one that passes makes it `healthy`
-  again. upaas reads the container's health once, 60 seconds after a deploy, and
-  fails the deploy unless it is `healthy`. A container that turns `unhealthy`
-  after that is neither restarted nor reported by upaas, whose `unless-stopped`
-  restart policy ignores health; only `docker ps` and `docker inspect` show it.
-  The container also stops when either process exits.
+The [upaas](https://git.eeqj.de/sneak/upaas) app for netwatch needs:
 
-## Browser Compatibility
+- Port: container port `8080`.
+- Volume: container path `/data`.
+- Environment variables: none is required. Every setting in
+  [Settings](#settings) applies, with four differences in the image:
+    - `BIND_ADDRESS` has no effect. The backend listens on `127.0.0.1` inside
+      the container.
+    - `PORT` is nginx's public port, from 1 to 65535 and not `8081`, where the
+      backend listens inside the container.
+    - `DATA_DIR` must be `/data` or a path below it, written in full, with no
+      `.` or `..` part and no extra `/`. A path through a symbolic link is
+      refused unless the link is relative and stays inside `/data`.
+    - `TRUSTED_PROXIES` names the proxies nginx trusts, as IP addresses or CIDRs
+      separated by commas; the backend's own setting is fixed to `127.0.0.1/32`.
+      `bin/entrypoint.sh` gives a lone address a `/32` or `/128` and checks each
+      entry with `netwatch-server check-cidr`, which refuses what the backend
+      would refuse. Set and empty, nginx trusts no proxy, and every client
+      behind a proxy then shares the proxy's one allowance of
+      `REPORTS_PER_MINUTE`. A client that connects from a trusted address can
+      write its own `X-Forwarded-For`. A port Docker publishes can bring
+      connections from the Docker network's gateway, such as `172.17.0.1`, which
+      the default includes. Where that matters, name only the proxy's own
+      addresses.
+- Health: the image's `HEALTHCHECK`, described above.
 
-Requires a modern browser with ES modules, Fetch API, Canvas API, and CSS custom
-properties.
+The container stops at start when a variable holds a value it cannot use. The
+reason is in its log.
 
-## Limitations
+## Settings
 
-- **CORS**: The checks are cross-origin requests in `no-cors` mode, so the page
-  cannot read the answer, only time it: any answer counts as reachable, an error
-  page included.
-- **Local targets**: The cable modem at 192.168.100.1 and the detected gateway
-  answer only on a network that has them, and only when NetWatch is served from
-  localhost or a private address (see Monitoring targets).
-- **Network conditions**: Measurements reflect browser-to-endpoint latency,
-  which includes your local network, ISP, and internet routing.
+`netwatch-server` reads its settings from environment variables. It also reads a
+`.env` file in the directory it starts in, and a YAML file named
+`netwatch-server.yaml` in `/etc/netwatch-server/` or
+`~/.config/netwatch-server/`, when one exists. A variable in the environment
+wins over a file.
+
+The server does not start when a variable holds a value it cannot use. Its error
+names the variable. An empty variable counts as unset, except `TRUSTED_PROXIES`.
+
+- `BIND_ADDRESS`, default empty: the IP address to listen on. Empty listens on
+  every interface. The image sets it to `127.0.0.1`.
+- `PORT`, default `8080`: the port to listen on, from 1 to 65535. In the image
+  this is nginx's port; the backend listens on `8081`.
+- `DATA_DIR`, default `./data/reports` (`/data/reports` in the image): the
+  directory for the report files. The server creates it if it is missing, and
+  stops at start if it cannot create a file in it.
+- `DATA_DIR_MAX_BYTES`, default `1073741824` (1 GiB): the most bytes of report
+  files kept in `DATA_DIR`, oldest deleted first. A positive whole number. See
+  [Report limits](#report-limits).
+- `REPORTS_PER_MINUTE`, default `60`: how many reports each client address may
+  send a minute. A positive whole number. See [Report limits](#report-limits).
+- `TRUSTED_PROXIES`, default `10.0.0.0/8,172.16.0.0/12,192.168.0.0/16`: the
+  reverse proxies whose `X-Forwarded-For` and `X-Real-IP` headers are trusted,
+  as CIDRs separated by commas. See [Trusted proxies](#trusted-proxies).
+- `CORS_ALLOWED_ORIGINS`, default empty: other origins whose pages may call the
+  API, separated by commas. See [CORS](#cors).
+- `METRICS_USERNAME` and `METRICS_PASSWORD`, default empty: the basic auth
+  credentials for `/metrics`. See [Metrics](#metrics).
+- `SENTRY_DSN`, default empty: the DSN of a Sentry project. Each request whose
+  handling crashes is reported there; the request still gets a 500.
+- `DEBUG`, default empty: any non-empty value turns debug logging on, `false`
+  and `0` included. Every value is accepted.
+
+### Trusted proxies
+
+Each `TRUSTED_PROXIES` entry must be a CIDR, such as `127.0.0.1/32`; a lone
+address is refused. A list replaces the default; set and empty, the server
+trusts no proxy. Loopback is not in the default, so a reverse proxy on the same
+host has to be named.
+
+A request from a peer outside this set has its forwarded headers ignored; the
+peer's own address is logged and rate limited. From a peer inside the set, the
+client address is the right-most `X-Forwarded-For` entry that is not in the set.
+The peer's address is used when every entry is in the set, or when the search
+from the right meets an entry that is not an address, such as `unknown`.
+`X-Real-IP` is read only when `X-Forwarded-For` is missing or empty.
+
+### Routes
+
+- `POST /api/v1/reports` takes a report from the page. It needs no credentials;
+  [Report limits](#report-limits) bound it instead.
+- `GET /.well-known/healthcheck` answers 200 with a JSON object: `appname`,
+  `version`, `now`, `uptime_seconds`, `uptime_human` and `status`, which is
+  `"ok"`. While report files cannot be written, it answers 503 with the same
+  fields and `"status":"error"`.
+- `GET /metrics` serves Prometheus metrics, only when `METRICS_USERNAME` and
+  `METRICS_PASSWORD` are set. See [Metrics](#metrics).
+
+Every request body is capped at 1 MiB, and every request at 60 seconds.
+
+### Report storage
+
+The server keeps the reports it takes in memory and writes them to `DATA_DIR` as
+files of JSON lines, compressed with zstd. It writes a new file every minute,
+whenever 10 MiB of reports are waiting, and when it stops. With none waiting, it
+writes no file. The files are named `reports-<timestamp>-<number>.jsonl.zst`;
+the timestamp is UTC to the millisecond, so the names sort by time.
+
+The reports of a failed write, as on a full disk, stay in memory for the next
+write to try again. Until a write succeeds, `POST /api/v1/reports` refuses every
+report with 500 and the health check answers 503.
+
+### Report limits
+
+`POST /api/v1/reports` takes reports from anyone who can reach it, so it is
+bounded in four ways. Each refusal by the backend answers with the body
+`{"status":"error"}`.
+
+- JSON only. A report must be sent with `Content-Type: application/json`; any
+  other content type is refused with 415, and malformed JSON with 400.
+- Body limit. A report body may be at most 1 MiB. A request that declares a
+  longer body, or a report that runs past that, is refused with 413.
+- Rate limit. Each client address may send `REPORTS_PER_MINUTE` reports a
+  minute; past that it gets 429 with `Retry-After: 60`. The page sends one
+  report a minute from each open tab, so the default of 60 refuses nothing from
+  up to 30 tabs behind one address.
+- Size cap. The report files in `DATA_DIR` may total at most
+  `DATA_DIR_MAX_BYTES`, counting the files already there at start and the
+  reports waiting in memory. When a report would take the total past the cap,
+  the oldest files are deleted to make room. A report is refused with 507 when
+  deleting the oldest files cannot make room.
+
+At the defaults, one address can fill the 1 GiB cap with its own reports in
+about 17 minutes, and every report stored before them is deleted to make room.
+
+### CORS
+
+The page needs no entry here: it calls the API from the origin it is served
+from. By default the server sends no CORS headers, and browsers let no other
+origin's pages call it. `CORS_ALLOWED_ORIGINS` lists other origins, such as
+`https://netwatch.example.com`, whose pages may then call the API with `GET` and
+`POST`. Each entry must be a plain origin as browsers send it: `scheme://host`,
+with an optional `:port`, no path, no trailing `/` and no `*`.
+
+### Metrics
+
+With both `METRICS_USERNAME` and `METRICS_PASSWORD` set, the server serves
+Prometheus metrics at `GET /metrics`. A request with those as its basic auth
+credentials gets them; any other gets 401. With neither set, `/metrics`
+answers 404. The metrics record each request that reaches the health check or
+`POST /api/v1/reports`: its duration and response size, labelled with its path,
+method and status. Each client address may make 60 requests to `/metrics` a
+minute. Past that it gets 429 with `Retry-After: 60`, and its credentials are
+not checked.
+
+### Logging
+
+The backend logs JSON to stdout, or plain text when stdout is a terminal. Each
+request is logged with its method, URL, status, client address and duration.
+Every value taken from a request is cut to 128 bytes before it is logged.
+
+## Design
+
+The repository holds the page, the backend and the image:
+
+- `web/`: the page's source. `index.html` loads `src/main.js` and
+  `src/styles.css`.
+- `cmd/netwatch-server/` and `internal/`: the Go backend. `cmd/` holds only
+  `main`, which calls into `internal/cli`.
+- `configs/`: nginx's configuration for the image, `nginx.conf` and
+  `security-headers.conf`.
+- `bin/entrypoint.sh`: the image's entrypoint.
+- `Dockerfile`: the lint and test phases, the two build stages and the image.
+- `script/`: the development commands; `Makefile` targets call them.
+- `test/unit/`: the page's unit tests. `test/viewport/`: the layout test.
+
+### The page
+
+The page is built with Vite and Tailwind CSS v4. All its code is in
+`web/src/main.js`:
+
+- `CONFIG`: the timing and display constants. The interval menu sets its
+  `updateInterval`; the check timeout and the history span follow from it.
+- `WAN_HOSTS`: the WAN targets, each with its URL and, for the S3 entries, the
+  method `HEAD`.
+- `HostState` and `AppState`: one host's history and status, and the whole
+  page's state.
+- `measureLatency`: one check. `tick`: one round, which checks every host in
+  parallel and draws each row as soon as its check ends.
+- `SparklineRenderer`: the graphs. `buildUI`, `updateHostRow`, `updateSummary`
+  and `updateHealthBox`: the page and its parts.
+- `Reporter`: builds and posts the reports. `buildReport` is a pure function of
+  the hosts' state.
+
+### The backend
+
+`netwatch-server` is a Go HTTP server. The `fx` library starts and stops its
+parts in dependency order. The backend's packages are in `internal/`:
+
+- `cli`: the command line: the server when given no arguments, or the
+  `check-cidr` and `prepare-data-dir` subcommands that `bin/entrypoint.sh` runs.
+- `config`: reads the settings and refuses values the server cannot use.
+- `server`: the router, the routes and the HTTP server.
+- `middleware`: the request log, the security headers, CORS, the body limit, the
+  rate limit, the client address resolution and the metrics.
+- `handlers`: the health check and the report route.
+- `reportbuf`: the in-memory buffer of reports and the files it writes them to.
+  It also holds `PrepareDataDir`, which `prepare-data-dir` runs.
+- `healthcheck`, `logger` and `globals`: the health status, the logger, and the
+  name and version the build stamps in.
+
+## Development
+
+### Entrypoints
+
+This repository adheres to the
+[Scripts to Rule Them All](https://github.com/github/scripts-to-rule-them-all)
+standard. The scripts in `script/` are the entrypoints for the development
+workflow, and the `Makefile` targets are thin shims that call them.
+
+- `script/bootstrap`: install the dependencies. It installs the pinned node,
+  yarn and Go when the ones on `PATH` do not pass its checks, and links them
+  into `~/.local/bin`, which has to be on `PATH`. It installs no Go linter and
+  no Docker.
+- `script/setup`: `script/bootstrap`, then the git pre-commit hook.
+- `script/dev`: run the Vite dev server.
+- `script/build`: build the page into `dist/`, then the static `netwatch-server`
+  binary into the repo root. Its version is `VERSION` from the environment, else
+  `git describe --tags --always --dirty`, else `dev`.
+- `script/run`: `script/build`, then run `netwatch-server` with its defaults.
+- `script/clean`: remove what `script/build` writes.
+- `script/projectname`: print `netwatch`, the image tag `script/docker` uses.
+- `script/yarn`: run yarn under the node `script/bootstrap` would use.
+- `script/test`: build the `test` phase of `Dockerfile`, writing no image: the
+  Go tests with the race detector and coverage, and the page's unit tests.
+- `script/lint`: build the `lint` phase of `Dockerfile`, writing no image:
+  golangci-lint over the Go packages and eslint over the JavaScript.
+- `script/fmt`: run the formatters: prettier over the JavaScript, CSS, HTML and
+  Markdown, then gofmt over `cmd/` and `internal/`. They write the files in
+  place.
+- `script/fmt-check`: check the formatting (read-only), with the same scope as
+  `script/fmt`.
+- `script/check`: `script/test`, `script/lint` and `script/fmt-check`.
+- `script/add-dependency`: add a page dependency, or move one to another
+  version: `make add-dependency PACKAGE=<name>@<version>`.
+- `script/tidy`: run `go mod tidy`.
+- `script/frontend-test`: run the unit tests in `test/unit/` on the host, with
+  Node's built-in test runner, then the production build.
+- `script/frontend-fmt` and `script/frontend-fmt-check`: the prettier half of
+  `script/fmt` and `script/fmt-check`.
+- `script/frontend-viewport-test`: check the built page's layout in a
+  containerised headless Chrome, not as part of `script/check`; see
+  [test/viewport/README.md](test/viewport/README.md).
+- `script/docker`: build the image from `Dockerfile`, tagged `netwatch`.
+- `script/cibuild`: `script/bootstrap`, `script/check`, then the image build.
+  The Gitea workflow `.gitea/workflows/check.yml` runs it on every push.
+- `script/precommit`: run by the git pre-commit hook; it runs `script/check`.
+- `script/install-precommit`: install the git pre-commit hook. `make hooks`
+  calls it.
+
+### Tests
+
+`make test` runs the backend's Go tests and the page's unit tests in Docker. The
+unit tests import `web/src/main.js` in Node and call the functions it exports;
+no browser is involved. `make frontend-viewport-test` checks the built page's
+layout in a headless Chrome; [test/viewport/README.md](test/viewport/README.md)
+says what it checks and what it cannot.
 
 ## TODO
 
-The to-do list is [TODO.md](TODO.md): where the work stands, the next step, the
-open work, and what has been done.
+The to-do list is [TODO.md](TODO.md): where the work stands, the next step and
+the open work.
 
 ## License
 

TODO.md

@@ -2,744 +2,24 @@
 
 - branch from `next`
 - do the work in Next Step
-- move Next Step to the top of Completed Steps
+- delete Next Step from `TODO.md`
 - move the top item of Future Steps into Next Step
 - commit (`TODO.md` changes in the same commit as the work)
 - push the branch and open a PR against `next`
 
 # Status
 
-pre-1.0. Release candidates are tagged on `next`, the first being `v1.0.0-rc1`;
-`git tag --merged origin/next` lists them. `main` is the stable branch and
-`next` the development branch, which every PR targets. The frontend and the Go
-backend ship as one Docker image, and the Gitea workflow
-`.gitea/workflows/check.yml` runs `script/cibuild` on every push, and cancels
-the older run on the same branch. Working toward 1.0.0.
+pre-1.0. Release candidates are tagged on `next`; `git tag --merged origin/next`
+lists them. `main` is the stable branch and `next` the development branch, which
+every PR targets. The frontend and the Go backend ship as one Docker image. The
+Gitea workflow `.gitea/workflows/check.yml` runs `script/cibuild` on every push,
+and cancels the older run on the same branch. Working toward 1.0.0.
 
 # Next Step
 
 Run `make frontend-viewport-test` in CI as its own step; it is not part of
 `make check`, as it needs Docker and takes minutes.
 
-# Completed Steps
-
-- 2026-10-19: the server's `OnStart` hook in `internal/server/server.go` starts
-  `listenAndServe` with `go func() { s.listenAndServe() }()`, as the Go style
-  guide asks ([#162](https://git.eeqj.de/sneak/netwatch/issues/162)); it was
-  `go s.listenAndServe()`. No other `go` statement in the Go code called a
-  function directly. Nothing the server does changed
-- 2026-10-19: `.gitignore`, `.editorconfig` and `.golangci.yml` are the
-  sneak/prompts copies at `0653579`
-  ([#174](https://git.eeqj.de/sneak/netwatch/issues/174)). `.gitignore` is the
-  standard file followed by this repository's own entries; `.editorconfig` is
-  the standard file alone, which now carries the `[*.go]` section.
-  `.golangci.yml` disables `canonicalheader`, as the canonical copy does,
-  because golangci-lint v2.14.0 misses its findings at random
-- 2026-10-19: `package.json` has no `version` field and is marked
-  `"private": true` ([#158](https://git.eeqj.de/sneak/netwatch/issues/158)). It
-  said `1.0.0`, a release that has not been made, and nothing read it; the git
-  tag is the one version, which the image and `make build` take from
-  `git describe --tags`. The package is never published
-- 2026-10-19: Status names `v1.0.0-rc1`, the first release candidate, and says
-  release candidates are tagged on `next`, where it said there were no git tags
-  ([#157](https://git.eeqj.de/sneak/netwatch/issues/157)). The rest of Status
-  matches the tree
-- 2026-10-19: `netwatch-server` starts the server only when given no arguments
-  ([#179](https://git.eeqj.de/sneak/netwatch/issues/179)). `check-cidr CIDR` and
-  `prepare-data-dir DATA_DIR` behave as before; any other arguments, such as a
-  subcommand with no value or two, or a misspelt one, print a one-line usage
-  message naming both forms to stderr and exit 2. They used to start the server.
-  Unit tests call `cli.Main` with no arguments and check that it starts the
-  server, and with each subcommand given no value and two values and with a
-  misspelt subcommand, and check the exit code, the message and that the server
-  does not start
-- 2026-10-19: `main()` in `cmd/netwatch-server/main.go` is one call into a new
-  package, `internal/cli`, as the Go style guide asks
-  ([#160](https://git.eeqj.de/sneak/netwatch/issues/160)). `internal/cli` runs
-  the `check-cidr` and `prepare-data-dir` subcommands, with the same arguments,
-  messages and exit codes, and otherwise the server, with the `fx` wiring.
-  `Appname` and `Version` stay in `main`, where the build sets `Version`, and
-  `main` gives `cli.Main` stderr and the function that runs the server, which
-  the tests replace with a buffer and a function that fails them. Unit tests
-  call `cli.Main` with `check-cidr` and a CIDR the server takes and one it
-  refuses, and check the exit code and what it writes to stderr, and with
-  `prepare-data-dir` and a path outside `/data`, and check that it exits 1 with
-  the error from looking up the `netwatch` user, which the test image does not
-  have. Others give the functions behind the subcommands input they take and
-  input they refuse, and check the exit code and what they write to stderr
-- 2026-10-19: when `VERSION` is unset or empty, `script/build` stamps the
-  version from `git describe --tags --always --dirty`, as `script/docker` does
-  ([#156](https://git.eeqj.de/sneak/netwatch/issues/156)). Without `--tags` it
-  skipped lightweight tags, so `make run` could report a commit where the image
-  built from the same tree reported the tag. Checked once with a lightweight tag
-  on a scratch clone: `make build` stamped it
-- 2026-10-19: `.dockerignore` keeps Go test binaries and coverage output at the
-  root out of the build context, with `/*.test` and `/*.out` in the repository's
-  own section ([#155](https://git.eeqj.de/sneak/netwatch/issues/155)). Such
-  files went into the build context of every `docker build` in `script/` and
-  were copied into the lint, test and build stages. Checked with a probe image
-  that copies the whole context: `x.test` and `x.out` planted at the root no
-  longer land in it, and nothing else changed. The entries match only at the
-  root, so the same files in a subdirectory still reach the image
-- 2026-10-19: `.gitea/workflows/check.yml` is the sneak/prompts copy at
-  `0653579` ([#153](https://git.eeqj.de/sneak/netwatch/issues/153)). Its
-  checkout step sets `fetch-depth: 0`, so CI clones all history and tags, and
-  `git describe` in `script/cibuild` gives the image built from a tagged commit
-  the tag as its version; it gave the short commit. The checkout step also sets
-  `persist-credentials: false`, so the job's token is not left in `.git/config`.
-  A new push cancels the older run on the same branch, and a run stops after 20
-  minutes
-- 2026-10-19: `script/bootstrap` keeps the `yarn` on `PATH` only when
-  `yarn --version` is exactly `YARN_VERSION`, and otherwise installs that
-  version as it did when no yarn was installed
-  ([#154](https://git.eeqj.de/sneak/netwatch/issues/154)); any yarn used to be
-  kept. It uses the `node` on `PATH` only when that node has the major version
-  of `NODE_VERSION`, as `REPO_POLICIES.md` asks, and is at least
-  `NODE_MIN_VERSION`; a node 24 was kept before. After installing node or yarn
-  it looks the tool up through `PATH` again and stops if that one fails the same
-  check, as it does for Go, and it prints the node and yarn versions it uses.
-  Every script that runs yarn on the host, except `script/bootstrap`, which
-  picks its own node and yarn, runs it through the new `script/yarn`. That
-  script puts `~/.local/bin` first on `PATH`, uses the first `node` on that
-  `PATH` when it passes the same test, and otherwise runs yarn under the pinned
-  node in nvm; `make build` ran yarn under whatever node was first on `PATH`
-- 2026-10-19: `bin/entrypoint.sh` has each of its steps in a function, and a
-  `main` at the end calls them in order, as the shell section of the code style
-  guide asks ([#163](https://git.eeqj.de/sneak/netwatch/issues/163)). It is
-  still POSIX sh with no `set -e`, and does what it did, with the same messages
-  and exit codes. Checked by running the image with each script: a normal start,
-  bad `PORT`, `TRUSTED_PROXIES` and `DATA_DIR` values, `docker stop`, INT, and
-  nginx exiting on its own
-- 2026-10-19: while report files cannot be written, the health check answers 503
-  with `"status":"error"` and the same fields, so the image's `HEALTHCHECK`
-  reports the container `unhealthy`
-  ([#142](https://git.eeqj.de/sneak/netwatch/issues/142)). It answered 200
-  `"status":"ok"` whatever happened, so the platform saw a healthy container
-  while every report was refused with 500. It answers 200 at start, before any
-  write has failed, and again from the first write that succeeds. A unit test
-  removes `DATA_DIR` to make a write fail and checks the 503, then puts it back
-  and checks the 200 after the next write
-- 2026-10-19: report file writes no longer overlap
-  ([#150](https://git.eeqj.de/sneak/netwatch/issues/150)), so the reports of
-  failed writes are written in the order they arrived. Two writes that failed at
-  the same time put their reports back in the wrong order when the older failed
-  first. One write runs at a time, and each takes the waiting reports only when
-  it starts, after a failed write has put its own back. The write `Append`
-  starts when 10 MiB are waiting waits for any write under way, and `Append`
-  starts no other while it waits. Files written since the start are deleted to
-  make room in the order they were written, after those found at start. A unit
-  test holds a write open, starts a second at 10 MiB, fails both and checks the
-  order in the next file. Others check that `Append` starts no second write at
-  10 MiB while one waits, that it starts one again the next time 10 MiB are
-  waiting, and that the first file written since the start is the first deleted
-- 2026-10-19: `DEBUG` unset or empty leaves debug logging off, and any other
-  value, `false` and `0` included, turns it on, as the code style guide says
-  ([#159](https://git.eeqj.de/sneak/netwatch/issues/159)). No value of it stops
-  the start any more; before, only `1`, `t`, `T`, `TRUE`, `true`, `True`, `0`,
-  `f`, `F`, `FALSE`, `false` and `False` were accepted. `README.md` no longer
-  gives `false` as its default
-- 2026-10-19: check builds keep Go's modules and compiled packages between runs
-  ([#118](https://git.eeqj.de/sneak/netwatch/issues/118)), on sneak's rulings in
-  [prompts#113](https://git.eeqj.de/sneak/prompts/issues/113) and
-  [prompts#130](https://git.eeqj.de/sneak/prompts/issues/130).
-  `REPO_POLICIES.md`, `script/test`, `script/lint`, `script/docker` and
-  `script/cibuild` are the sneak/prompts copies at `0653579`: the scripts pass a
-  new `CACHEBUST` value where they passed `--no-cache`, and the lint and test
-  builds write no image. In each stage of `Dockerfile`, `ARG CACHEBUST` comes
-  after the system packages and the Go module download, and before every step
-  that lints, tests or compiles and the node stages' `yarn install`. Go's build
-  cache and golangci-lint's are cache mounts, and both `go test` runs carry
-  `-count=1`. The test phase's Go caches used to be in memory, empty on every
-  build
-- 2026-10-19: the three unit tests of a check whose result is discarded (its
-  round given up, the user paused, or the first round) also check that the
-  host's history is still empty, its status still `pending`, and nothing was
-  written to the console
-  ([#151](https://git.eeqj.de/sneak/netwatch/issues/151)). They checked only the
-  row, so a change that recorded the result and skipped only the row would have
-  kept them passing
-- 2026-10-18: when the backend runs on its own, a `DATA_DIR` that cannot be
-  created or read, or where no file can be created, stops the start with an
-  error naming `DATA_DIR` and its value, as the other settings' errors do
-  ([#148](https://git.eeqj.de/sneak/netwatch/issues/148)); the first two named
-  only the path, and the third was found only at the first write of a report
-  file. At start the server creates a file in `DATA_DIR` and removes it. Unit
-  tests start the buffer with `DATA_DIR` below a regular file and with
-  `DATA_DIR` set to `/proc`, and check the error. The report file number is an
-  `atomic.Int64`, as the Go style guide asks for int types
-  ([#161](https://git.eeqj.de/sneak/netwatch/issues/161)); file names are
-  unchanged
-- 2026-10-18: the image's nginx sends the page with `Cache-Control: no-cache`
-  ([#141](https://git.eeqj.de/sneak/netwatch/issues/141)), so a browser that
-  keeps a copy checks with the server that it is current before using it again.
-  The page went out with no `Cache-Control`, so a browser could keep it after a
-  deploy and ask for files under `/assets/` that the new build no longer has,
-  and show an empty page. A path that `location /` answers with the page through
-  its `try_files` fallback gets the same header. `location /` now includes the
-  security headers again, as `/assets/` does, since its own `add_header` drops
-  the server's. `/assets/` keeps its immutable caching.
-  `make frontend-viewport-test` fails unless `/` and a path that falls back to
-  the page carry `Cache-Control: no-cache` and `Content-Security-Policy`, which
-  comes from the same file as the other security headers
-- 2026-10-18: `README.md` says what the page loses while reports are refused or
-  the page is paused ([#145](https://git.eeqj.de/sneak/netwatch/issues/145)),
-  how fast one address can replace the stored reports
-  ([#146](https://git.eeqj.de/sneak/netwatch/issues/146)), and that in the image
-  nginx answers a body over 1 MiB itself
-  ([#147](https://git.eeqj.de/sneak/netwatch/issues/147)). A sample in the
-  history that no report has delivered is sent only as long as the history holds
-  it: at the 1-second interval one refused or failed report loses the oldest 20
-  seconds of each host's samples, and a pause longer than the history loses
-  every sample between the last delivered report and the pause. Samples an
-  interval change cleared are kept apart, the last 100 per host, until they are
-  delivered. At the defaults, one address sending 1 MiB reports made up to
-  compress badly can fill the 1 GiB cap in about 17 minutes. nginx's
-  `client_max_body_size` is also 1 MiB by default, so in the image it answers a
-  larger body with 413 and its own HTML page, and the backend never sees or
-  records it; the backend's own 413 sentences now say they apply to it run on
-  its own. The reporter, the body limit and nginx are unchanged
-- 2026-10-18: a browser that cannot format the header's clocks still probes
-  ([#149](https://git.eeqj.de/sneak/netwatch/issues/149)). The clocks name the
-  local time zone through `Intl.DateTimeFormat`'s `shortGeneric` option, which
-  Chrome before 95, Firefox before 91 and Safari before 15.4 reject with an
-  error; it came before the first round started, so such a browser never checked
-  a target. The clocks now start last, after the rounds, and an error formatting
-  them leaves both blank. The footer's color legend reads `>=500ms` for red,
-  where it read `>500ms`, so 500 ms, which is red, is in one of its colors
-  ([#152](https://git.eeqj.de/sneak/netwatch/issues/152)). Unit tests check the
-  clocks with a working `Intl.DateTimeFormat` and with one that rejects
-  `shortGeneric`, and draw the page and check the legend against every entry of
-  `CONFIG.latencyColors`
-- 2026-10-18: `netwatch-server prepare-data-dir` no longer changes the owner of
-  a file outside `/data` through a hard link in the volume
-  ([#143](https://git.eeqj.de/sneak/netwatch/issues/143)). A file with a second
-  name (hard link) keeps its owner, and the start logs its path. Owners are now
-  set on the opened directory, file or link, never by name, so a hard link
-  swapped in after the check is caught too; a symbolic link is opened without
-  following it and given to the netwatch user itself, so the server can still
-  follow one in a sticky directory that anyone can write to. Devices, named
-  pipes and sockets keep their owner. Setting the owner on an open file that is
-  not a directory is built only for Linux: `prepare-data-dir` runs only in the
-  Linux image, and macOS, where the backend is also built for development, has
-  neither `O_PATH` nor `AT_EMPTY_PATH`. On any other system the package still
-  builds, and `prepare-data-dir` fails at the first file that is not a
-  directory. The test that runs as root hard-links a file, a symbolic link and a
-  named pipe from outside the volume into it and finds their owners unchanged
-- 2026-10-18: from a trusted proxy, the backend takes the client address from
-  the right-most `X-Forwarded-For` entry that is not in `TRUSTED_PROXIES`
-  ([#144](https://git.eeqj.de/sneak/netwatch/issues/144)). It took the left-most
-  entry, which the client writes itself behind a proxy that appends to the
-  header, so a client could choose the address the rate limit counts and the
-  request log records. An entry written as an address with a port is read as
-  that address. With only trusted addresses in the header, or an entry that is
-  not an address at all (such as `unknown`) met on the way, the direct peer is
-  used. `X-Real-IP` is read only without `X-Forwarded-For`, and every
-  `X-Forwarded-For` header line is read, not only the first. The image's nginx,
-  and the `TRUSTED_PROXIES=127.0.0.1/32` it starts the backend with, are
-  unchanged; the comment in `configs/nginx.conf` that said the backend takes the
-  first entry now says it takes the one address nginx passes on. Unit tests
-  resolve the address from chains ending in an untrusted address, in trusted
-  ones, of only trusted ones, with ports, with an entry that is not an address,
-  and split over two header lines
-- 2026-10-18: after an interval change, the summary's Reachable slot reads
-  `--/--` in white, as at page load, until the second round since the change
-  ends ([#140](https://git.eeqj.de/sneak/netwatch/issues/140)). It used to read
-  0/26 in red from the change on, as no WAN host had a check recorded, for up to
-  two intervals with the network fine. The summary update now writes `--/--`
-  while every WAN host still waits for its first check. A unit test resets the
-  hosts as the interval menu does and checks the slot; another checks that it
-  reads 0/26 in red once every WAN host's check has failed
-- 2026-10-14: stopping the server waits for a report file write already under
-  way, the periodic flush's or the one `Append` starts when 10 MiB are waiting,
-  before the final flush
-  ([#122](https://git.eeqj.de/sneak/netwatch/issues/122)). It used to return at
-  once, and the process exiting cut the write off, losing its reports. A write
-  under way that fails puts its reports back in memory, so the final flush
-  writes them; the stop fails, and the process exits non-zero, only if that
-  flush fails too. Two tests hold the periodic write and the one at 10 MiB open
-  and find the stop waiting until each is released; a third makes the held write
-  fail and finds its report written by the final flush. They run in a
-  `testing/synctest` bubble, so the periodic flush comes without waiting a
-  minute
-- 2026-10-14: `make test` no longer runs the frontend's production build, which
-  the tests do not need ([#118](https://git.eeqj.de/sneak/netwatch/issues/118)).
-  `yarn build` moved out of the stage that runs the frontend's unit tests, now
-  named `frontend-test`, into a new `frontend-build` stage, which starts from it
-  and, like the `builder` stage, waits on the lint and test phases, so the image
-  still cannot be built unless they pass. The runtime stage copies `dist/` from
-  it, and the `git` that `vite.config.js` reads the commit with is installed
-  there. No build cache was added
-- 2026-10-14: opening the debug log no longer raises the measured latencies
-  ([#131](https://git.eeqj.de/sneak/netwatch/issues/131)). With the panel open,
-  each line written drew the panel again with every line before it, up to 1000,
-  and a check that ends while the page draws is timed only when the drawing is
-  done. Each line is now added at the end of the open panel, its first line is
-  dropped once it holds more than 1000, and it scrolls to its newest line once a
-  frame rather than once a line; the whole panel is drawn only when it is
-  opened. A unit test writes more lines than the panel keeps and checks that the
-  lines already shown are left as they are
-- 2026-10-14: unset, the backend's own `TRUSTED_PROXIES` trusts `10.0.0.0/8`,
-  `172.16.0.0/12` and `192.168.0.0/16`, and no longer loopback; a list replaces
-  that; set and empty, it trusts no proxy, where it used to get the default, as
-  viper reads an empty environment variable as unset
-  ([#129](https://git.eeqj.de/sneak/netwatch/issues/129)). A value it cannot
-  parse still stops the start, and the image still starts the backend with
-  `TRUSTED_PROXIES=127.0.0.1/32`. Tests load the config with it unset, empty and
-  set to a list
-- 2026-10-14: while report files cannot be written, `POST /api/v1/reports`
-  answers 500, and storing recovers once writing works again, with no restart
-  ([#123](https://git.eeqj.de/sneak/netwatch/issues/123)). A failed write puts
-  its reports back in the report buffer, still counted against
-  `DATA_DIR_MAX_BYTES`, where they used to be lost; the next flush, within a
-  minute, tries them again. Until a write succeeds, every report is refused and
-  nothing of it is kept, so the buffer does not grow while writes fail. A test
-  posts reports through the report handler before, during and after a failure;
-  others check that a report appended while a write runs is kept, behind that
-  write's own, when the write fails, and that the cap still holds exactly once a
-  failed write's reports are written
-- 2026-10-14: a request whose handler panics is logged with status 500 and
-  counted with `code` 500 in the metrics
-  ([#125](https://git.eeqj.de/sneak/netwatch/issues/125)), not 200. `Recoverer`
-  is still the first middleware; `Write500OnPanic`, after the request log and
-  after the metrics, writes the 500 as the panic passes and lets it go on to
-  Sentry and `Recoverer`, which now writes a 500 only when no status was written
-- 2026-10-14: with `TRUSTED_PROXIES` unset, the container's nginx trusts the
-  three private ranges of RFC 1918, `10.0.0.0/8`, `172.16.0.0/12` and
-  `192.168.0.0/16` ([#119](https://git.eeqj.de/sneak/netwatch/issues/119)), as
-  sneak ruled on 2026-09-22 for every app; it trusted no proxy before. A list
-  replaces them, and set and empty it trusts none. The backend inside the
-  container still trusts only `127.0.0.1/32`
-- 2026-10-14: `POST /api/v1/reports` takes only a report sent with
-  `Content-Type: application/json`, parameters such as `charset` allowed, and
-  refuses any other with 415 and the usual error body, storing nothing
-  ([#126](https://git.eeqj.de/sneak/netwatch/issues/126)). A page on another
-  origin can send a `text/plain` POST without a CORS preflight, so any site
-  could make its visitors' browsers store reports; a JSON POST waits for the
-  preflight, which only an origin in `CORS_ALLOWED_ORIGINS` passes. The page
-  already sent `application/json`. A test posts a report as `text/plain`, as
-  `application/x-www-form-urlencoded`, as `multipart/form-data`, with no
-  `Content-Type`, and as `application/json` with and without a charset, and
-  checks which are stored
-- 2026-10-14: changing the interval no longer drops the samples not yet reported
-  to the backend ([#124](https://git.eeqj.de/sneak/netwatch/issues/124)). The
-  interval menu resets each host with the new `HostState.reset`, which moves the
-  history's entries to `clearedHistory`, keeping the last 100 of all it has
-  cleared, and `buildReport` reads both, so the next report has the samples
-  recorded before the change that no report has delivered. Until its next check,
-  such a host is sent with the status of its last check, not `pending`. The
-  page's history still starts over, and the per-host marks still leave out of a
-  report the samples a delivered one had. Unit tests reset a host as the
-  interval menu does and find its unreported samples in the next report, and
-  only the last 100 after more were cleared; `web/src/main.js` now exports
-  `Reporter` for them
-- 2026-10-14: the repo has the layout `REPO_POLICIES.md` gives
-  ([#30](https://git.eeqj.de/sneak/netwatch/issues/30)). The Go module is at the
-  root (`go.mod`, `go.sum`, `.golangci.yml`, `cmd/netwatch-server/`,
-  `internal/`), so its path `sneak.berlin/go/netwatch` names the repository.
-  `go.mod` ignores `node_modules/`, where npm packages can ship `.go` files that
-  `make tidy` would otherwise read as this module's packages. The page's source
-  is in `web/` (`index.html`, `src/`), which `vite.config.js` makes Vite's root;
-  the build still goes to `dist/`. `nginx.conf` and `security-headers.conf` are
-  in `configs/`. `backend/` is gone: its `LICENSE` and `.dockerignore` are
-  deleted, its `.gitignore` entries are in the root one, its `README.md` is
-  folded into the root `README.md`, and its scripts into the root `script/`:
-  `script/build` builds the server binary after the frontend, `script/run` and
-  `script/clean` came from `backend/script/`, and `make test`, `make lint`,
-  `make fmt` and `make fmt-check` do what its `test`, `lint`, `fmt` and
-  `fmt-check` did. `script/bootstrap` no longer installs gcc, which only the
-  host Go tests needed. The image and the page are unchanged
-- 2026-10-07: the files shared from `sneak/prompts` are its copies at commit
-  `dd4027b` ([#113](https://git.eeqj.de/sneak/netwatch/issues/113)), with this
-  repository's own entries after the shared content in `.gitignore`,
-  `.dockerignore` and `.editorconfig`. `make lint` and `make test` each build
-  one phase of `Dockerfile` without the cache: `lint` runs golangci-lint v2.14.0
-  over `backend/` and, through the `frontend-lint` stage, eslint; `test` runs
-  the Go tests on the Debian Go image and, through the `frontend` stage, the
-  frontend's unit tests and build. The builder stage waits on both, and without
-  a `VERSION` build argument takes the version from `git describe` on the `.git`
-  in the build context. Neither linter nor the tests run on the host for
-  `make check`; `backend/script/lint` runs the root one, and
-  `backend/.golangci.yml` is no longer checked against a sha256. prettier
-  formats only the JavaScript, CSS, HTML and Markdown, so the shared
-  `.golangci.yml` stays as fetched. `script/fmt` and `script/fmt-check` put
-  `~/.local/bin` on `PATH`, which the shared workflow no longer does.
-  `script/frontend-lint` and `script/frontend-check` are gone
-- 2026-10-07: the six Hetzner targets answer again, and failed checks are
-  written to the browser console
-  ([#114](https://git.eeqj.de/sneak/netwatch/issues/114)). The Hetzner
-  speed-test servers close the connection without an answer when the URL has a
-  query string, and every check added `?_cb=` and the time; checks now fetch
-  each target's URL as written, with `cache: 'no-store'` as before. Each
-  recorded check that fails writes one `console.error` line, and the same line
-  to the debug log, with the target's name and URL, the time, what failed and
-  how long the request took; a target that answers after failed checks writes
-  one `console.info` line. Checks the page does not record write none, so the
-  debug log no longer lists failures in the first round or in the recovery probe
-- 2026-10-04: the page's footer no longer says "IPv4 only"
-  ([#111](https://git.eeqj.de/sneak/netwatch/issues/111)): each check is a
-  `fetch`, the browser picks IPv4 or IPv6 for each WAN host, and the local
-  targets are IPv4 addresses. The rest of the footer is unchanged
-- 2026-10-04: `README.md`, `TODO.md` and `test/viewport/README.md` say what the
-  tree does (issue #24). The README's Getting Started leads with `make` targets;
-  a new Backend section says what `netwatch-server` stores, its routes and how
-  the image builds and runs it, and points to `backend/README.md` for its
-  settings; the checks are GET requests; the 26 WAN hosts, the four health
-  states, the summary's figures and the features the list lacked are described
-  as the page has them; and its TODO section points here, as does the one in
-  `backend/README.md`, whose open items moved to Future Steps. This file's
-  Workflow branches from `next` and opens the PR against `next`, Status says
-  where the repo stands, and Next Step and Future Steps hold only open work,
-  linked to its issue where one exists. The viewport harness README names Node's
-  test runner, not `vitest`
-- 2026-10-04: in `src/main.js` (issue #102), a target's min, max, median and
-  average latency come from one list of its answers, through the same function
-  the summary's figures use, so the median is written once. The latency color
-  limits are one table in `CONFIG`, read by both the figure's and the
-  sparkline's color. The health thresholds, the debug log's length, the gateway
-  check's timeout, the recovery probe's number of hosts and interval, how often
-  the rows are sorted and the delay before the first sparkline resize are
-  `CONFIG` entries too. A unit test checks the summary's figures. Nothing the
-  page does or shows changed; the footer's color legend still writes the limits
-  out as text
-- 2026-10-04: password guesses at `/metrics` are rate limited (issue #104): each
-  client address, resolved through `TRUSTED_PROXIES` as for reports, may make 60
-  requests to `/metrics` a minute, counted by `go-chi/httprate` apart from its
-  reports; past that it gets 429 and its basic auth credentials are not checked.
-  The limit is a constant in `backend/internal/server/routes.go`. A test uses up
-  one client's allowance on wrong passwords, gets 429 with the right one, and
-  checks that another client behind the same nginx still gets in
-- 2026-10-04: the backend reports errors to Sentry (issue #95). With
-  `SENTRY_DSN` set, it sets up `sentry-go` with the release `netwatch-server-`
-  and its version, reports each panic in a handler through `sentryhttp`, the
-  last of the middleware every request goes through, which panics again so the
-  request still gets the 500 from the panic recovery, and waits up to 2 seconds
-  on shutdown for Sentry to finish sending. A DSN Sentry refuses stops the start
-  with an error naming `SENTRY_DSN`. With it empty, Sentry is not set up and
-  nothing is sent to it
-- 2026-10-04: a target's name and URL and a debug log message show as the
-  characters they are and are never read as HTML (issue #29): a host row escapes
-  the name and URL it writes into its markup, and the debug log sets each line
-  as text. A unit test checks a target whose name and URL hold `<`, `>`, `"`,
-  `&` and `'`. `README.md` no longer calls `CONFIG` frozen: the interval menu
-  sets its `updateInterval`, and the values computed from it follow. `AppState`
-  declares the recovery probe's two properties, the sparkline axis functions
-  lose the parameters they did not use, and the comment on a target's history
-  names both kinds of entry it holds. Nothing the page does changed
-- 2026-10-04: a dependency can be added without running yarn or go by hand
-  (issue #45): `make add-dependency PACKAGE=<name>@<version>` shims to the new
-  `script/add-dependency`, which runs `yarn add --dev`, so `package.json` and
-  `yarn.lock` change together, then `yarn install --frozen-lockfile`; the same
-  command moves a package to another version. `make tidy` shims to the new
-  `script/tidy`, which runs `go mod tidy` in `backend/`: a Go module is added by
-  importing it, or moved by editing its `require` line, then `make tidy`.
-  `script/bootstrap` still installs with `--frozen-lockfile`
-- 2026-10-04: the backend serves Prometheus metrics (issue #94). With
-  `METRICS_USERNAME` and `METRICS_PASSWORD` both set, it records request
-  duration and response size through `go-http-metrics` and serves them, with
-  Go's runtime and process metrics, at `GET /metrics` behind basic auth with
-  those credentials; nginx passes `/metrics` to it as it does `/api/`. With
-  neither set there are no metrics and `/metrics` is 404; one without the other
-  stops the start with an error naming both, and so does a `METRICS_USERNAME`
-  containing `:`, with an error naming it. Only requests that reach the health
-  check or `POST /api/v1/reports` are recorded, not `/metrics` itself and not
-  every request as `GO_HTTP_SERVER_CONVENTIONS.md` shows, because the labels are
-  the request's path and method, which clients can make up without end. For
-  that, `POST /api/v1/reports` is now registered by its full path instead of
-  inside a `/api/v1` route group; it answers as before
-- 2026-10-04: `script/` and `Makefile` follow the org models (issue #28):
-  `make dev` shims to the new `script/dev`, the Vite dev server, and the new
-  `make build` to `script/build`, the frontend production build.
-  `.prettierignore` no longer leaves out `backend/`, so `make fmt` and
-  `make fmt-check` cover `backend/README.md`; it leaves out
-  `backend/.golangci.yml` by name, the org standard file whose sha256
-  `backend/script/lint` checks. `script/install-precommit` and the date on
-  `script/bootstrap`'s pins are the org model again; `script/bootstrap`,
-  `script/fmt` and `script/fmt-check` each say in a comment why they differ from
-  it
-- 2026-10-04: a frontend build on Node 26 or newer, such as `make test` on a
-  host with Node 26, no longer prints Node's warning that `module.register()` is
-  deprecated (issue #32); the build in `Dockerfile` runs on Node 22, which never
-  printed it. The call was in `@tailwindcss/node`, which `@tailwindcss/vite`
-  brings in at its own exact version; tailwind 4.3.1 calls
-  `module.registerHooks()` instead where Node has it. `yarn.lock` now has
-  `@tailwindcss/vite` and `tailwindcss` at 4.3.3, inside the ranges
-  `package.json` already allowed, and tailwind's own dependencies moved with
-  them. The built CSS changes only in how it is written out, in tailwind's
-  Firefox focus-ring rule, which no longer applies to iframes (the page has
-  none, so nothing on it looks different), and in tailwind's default sans-serif
-  font list, which the page does not use: `body` sets a monospace font
-- 2026-10-03: the frontend's unit tests cover what the page computes (issue
-  #21): `humanDuration`, the latency colours of a figure and of a sparkline
-  either side of each boundary, a target's min, max, average and median latency
-  over an empty history, an all-unreachable one and a mixed one, and each of the
-  four health states either side of its thresholds. `package.json` has a `test`
-  script, so `yarn run test` and `npm run test` run them, and
-  `script/frontend-test` runs it: quietly, and if a test fails, again with every
-  test listed, and then fails. `src/main.js` now exports `humanDuration`,
-  `HostState`, `latencyClass` and `latencyHex` for the tests; nothing it does
-  changed
-- 2026-10-03: the backend's logs are one stream (issue #27): fx logs its own
-  steps of starting and stopping through the backend's logger, so off a terminal
-  every line the backend's own logger and fx write is JSON, where fx used to
-  write plain text to stderr. A config file that is found but cannot be read now
-  stops the start with its error, logged as JSON like a bad setting, where it
-  used to end in a Go panic. A test runs the server as a child process and
-  checks both. The backend logs its name, version and architecture once at
-  start. The health check's uptime keys are now `uptime_seconds` and
-  `uptime_human`; its path, content type, `"status":"ok"` and 200 are unchanged.
-  `SENTRY_DSN`, `METRICS_USERNAME` and `METRICS_PASSWORD` are still read and
-  still unused, and left out of `backend/README.md`, until issues #94 and #95
-  wire them up
-- 2026-10-03: the frontend has a real linter (issue #47, and item 2 of issue
-  #28): `eslint` with its recommended rules, set in `eslint.config.js`, runs in
-  a new `frontend-lint` stage of `Dockerfile`, which the frontend stage waits
-  on, as the builder stage waits on the Go `lint` stage. `script/lint` builds
-  both stages without the cache and runs no linter on the host.
-  `script/frontend-lint` runs eslint where it used to repeat the prettier check
-  that `script/fmt-check` runs on the host, and `script/frontend-check`, run by
-  the frontend stage, is now the tests and the format check. `script/bootstrap`
-  wants node 22.13.0 or newer, as eslint 10 does
-- 2026-10-03: the tap-target check in `make frontend-viewport-test` expects one
-  visible pin button per WAN host row (issue #46), where it expected at least 10
-  of the 26, so pin buttons missing from only some rows now fail it. The host
-  row count the harness gathers, which the `app-rendered` check also reads, now
-  counts only the WAN host rows: the local host rows have no pin button
-- 2026-10-03: each target's row shows its result as soon as its check ends
-  (issue #91), where every row waited for the round's slowest check, up to 24
-  seconds at a 30-second interval. Every row is still redrawn, and sorting, the
-  summary, the health box and offline detection still run, once, when the
-  round's last check ends, so no row reads "paused" after a pause and resume
-  during the round. A check that ends after the user pauses or after its round
-  is given up shows nothing, and the first round is still discarded as a whole
-- 2026-10-03: root no longer acts outside `/data` when it prepares `DATA_DIR`
-  (issue #80): `bin/entrypoint.sh` runs `netwatch-server prepare-data-dir`,
-  which refuses a `DATA_DIR` that is not `/data` or a path below it written in
-  full, then creates `DATA_DIR`, gives `/data` and everything in it to
-  `netwatch` and sets the modes, all through a Go `os.Root` opened on `/data`.
-  That refuses any path leading out of `/data`, so neither a symbolic link
-  already there nor one a host process swaps in during the start can make root
-  create or change anything elsewhere, and `DATA_DIR=/etc` no longer gives
-  `/etc` to `netwatch`. The `README.md` section "Running under upaas" says which
-  values are accepted
-- 2026-10-03: `DATA_DIR_MAX_BYTES` is now how much of the report files is kept
-  (issue #54): when a report would take them past it, the oldest report files
-  are deleted to make room, each deletion logged, and at start files already
-  past it are deleted the same way. A file still being written is never deleted.
-  A report is refused with 507 only when the reports waiting to be written fill
-  the cap on their own, and then no file is deleted. The reports of a failed
-  write stop counting, and the part of its file written is removed. A file that
-  cannot be deleted still counts until the next start; one already deleted by
-  hand counts as freed
-- 2026-10-03: `backend/script/lint` says what went wrong with its
-  `.golangci.yml` check (issue #34). On a hash mismatch it says to compare the
-  file with the org standard: if they differ, restore the org standard; if they
-  are the same, the org standard changed, so update `GOLANGCI_CONFIG_SHA256` in
-  that script. It used to say only to restore the file, which loops once the org
-  standard itself has moved. A missing `.golangci.yml`, and a `sha256sum` that
-  is missing or prints no hash, each get their own message instead of being
-  reported as a mismatch; every one still fails the lint
-- 2026-10-03: the Go tests run with the race detector and coverage (issue #88):
-  `backend/script/test` runs `go test -timeout 30s -race -cover ./...` and, if
-  that fails, runs it again with `-v` and fails. Go's `-timeout` bounds the
-  tests, not their compile; the root `script/test` no longer puts one 30-second
-  timeout around both halves, which a cold Go build cache could use up on
-  compiling alone. The race detector needs a C compiler: the builder stage of
-  `Dockerfile` has gcc and musl-dev, and `script/bootstrap` installs gcc, with
-  the C library headers on apt and apk, when gcc is missing; the binary is still
-  built with `CGO_ENABLED=0`. New tests cover the health check's answer, a valid
-  report's answer, a report file's exact contents, and the flush when the buffer
-  reaches 10 MiB; the handlers' `TestImport` stub is gone
-- 2026-10-03: each target check times out after 80% of the refresh interval
-  (issue #78), 24 seconds at 30 seconds, where it was capped at 3 seconds. A
-  round started early, after an interval change or when the recovery probe finds
-  a target answering, gives up the last round's checks if they are still
-  waiting, so rounds never overlap; the recovery probe gives up its own checks
-  after half a second. The frontend has its first unit tests, run by
-  `script/frontend-test` with Node's built-in test runner; for them,
-  `index.html` now links `src/styles.css`, which `src/main.js` used to import
-- 2026-09-29: the container sets up its own data directory (issue #75):
-  `bin/entrypoint.sh`, still as root, creates `DATA_DIR` if missing and gives it
-  and `/data` to the `netwatch` user with mode 750 before starting the backend
-  as that user, so an empty host directory owned by root, or one holding files
-  from another uid, works with no step on the host. It stops the start instead
-  when a symbolic link is on the path to `DATA_DIR`, since root would change
-  whatever the link points to. The `README.md` first-run step that created and
-  chowned the host directory is gone, and the image no longer sets that
-  ownership at build time
-- 2026-09-29: CI can no longer pass on checks that did not run (issue #37):
-  `script/cibuild` is now the org model, byte for byte. It runs
-  `script/bootstrap` and `script/check`, then builds the image with `--no-cache`
-  and the version from `git describe` as the `VERSION` build argument, where it
-  used to be a plain `docker build .` whose check steps could come from the
-  build cache. The workflow puts `~/.local/bin`, where bootstrap links what it
-  installs, on the step's `PATH`, and bootstrap now installs its pinned node
-  when the installed one is older than the frontend's dependencies need
-- 2026-09-29: `backend/.golangci.yml` re-vendored from `sneak/prompts` (issue
-  #41): `gomodguard`, deprecated in golangci-lint v2.12.0, is disabled and its
-  successor `gomodguard_v2` enabled with the org block list, so lint runs print
-  no deprecation warning. The new file also turns `depguard` on with its
-  `test-support` rule, which keeps `net/http/httptest` out of non-test code;
-  netwatch adds no entries of its own to that rule. `backend/script/lint` checks
-  the new sha256
-- 2026-09-29: nginx sends the security headers `REPO_POLICIES.md` requires on
-  every response (issue #18), including errors, `/assets/` and what it passes on
-  from the backend, whose own copies it drops so each header goes out once. They
-  live in `security-headers.conf`, which `nginx.conf` includes. The content
-  security policy allows no inline script or style, so the status dot's grey in
-  `src/main.js` is now a class; `connect-src` is `*` because probed hosts
-  redirect to others, and the browser checks each redirect against it
-- 2026-09-29: the request log is bounded (issue #60): the method, URL, protocol,
-  `User-Agent`, `Referer`, request ID (which chi takes from the client's
-  `X-Request-Id` header) and client address it writes are each cut to 128 bytes,
-  the bound the report handler already used, so one request can no longer put
-  about 1 MiB per field into a log line. That bound and its helper now live in
-  the `logger` package, shared by both
-- 2026-09-29: nginx takes the client address from `X-Forwarded-For` only on
-  requests from the reverse proxies named in the container's `TRUSTED_PROXIES`
-  (issue #64), and by default from none, where it trusted every RFC1918 address
-  before, so a client could write a new address on each request and escape the
-  rate limit. `bin/entrypoint.sh` writes one `set_real_ip_from` line per entry
-  into `/etc/nginx/trusted-proxies.conf`, which `nginx.conf` includes, refusing
-  an entry that is not an IP address or CIDR, as `netwatch-server check-cidr`
-  finds; it starts the backend with `TRUSTED_PROXIES=127.0.0.1/32`, since nginx
-  is its only client
-- 2026-09-29: report file names can no longer collide (issue #61): each is
-  `reports-<timestamp>-<number>.jsonl.zst`, where the number goes up by one for
-  each file the server starts to write, so two flushes in the same millisecond,
-  such as a flush for size and the final flush at shutdown, each get a file of
-  their own instead of the second one failing. A failed write uses up its
-  number, leaving a gap if the file could not be created and otherwise a file
-  under that number that may be incomplete.
-- 2026-09-29: ready to run under upaas (issue #59): the image has a
-  `HEALTHCHECK` that requests `/.well-known/healthcheck` through nginx on the
-  port from `PORT`. The backend no longer reads a bad `PORT` as 0 or a bad
-  `DEBUG` as false: those, and a `BIND_ADDRESS` that is not an IP address, stop
-  it from starting with an error naming the variable, as the limits,
-  `CORS_ALLOWED_ORIGINS` and, now by name, `TRUSTED_PROXIES` already did.
-  `bin/entrypoint.sh` also refuses a `PORT` outside 1 to 65535, and `8081`,
-  where the backend listens inside the container, naming `PORT`. `README.md` has
-  a "Running under upaas" section, whose first-run steps create the host
-  directory for `/data` owned by uid 1000; the image does not change its owner
-- 2026-09-29: nginx listens on `PORT` (issue #26), 8080 when unset or empty: the
-  nginx image renders `nginx.conf` as a template at container start, filling in
-  `PORT` and no other variable. `bin/entrypoint.sh` refuses to start when `PORT`
-  is not digits only. `server_tokens off` keeps the nginx version out of
-  responses. `script/frontend-viewport-test` renders the template the same way.
-  Gzip and a `50x.html` error page are not added
-- 2026-09-29: bounded the report endpoint (issue #20): `POST /api/v1/reports`
-  still needs no credentials, but each client address, as resolved through
-  `TRUSTED_PROXIES`, may send `REPORTS_PER_MINUTE` (default 60) reports a
-  minute, counted by `go-chi/httprate`, and past that gets 429 with
-  `Retry-After`; the report files in `DATA_DIR`, counted from start with those
-  already there, may total at most `DATA_DIR_MAX_BYTES` (default 1 GiB), past
-  which reports get 507; and the wildcard CORS is gone: no CORS headers unless
-  `CORS_ALLOWED_ORIGINS` lists origins, and an entry that is not a plain
-  `scheme://host[:port]` origin, `*` included, stops the server from starting.
-  Deleting report files frees room only at the next start; pruning is issue #54
-- 2026-09-28: one container image (issue #52): the root `Dockerfile` builds the
-  only image, and `Dockerfile.backend` is gone. nginx serves the frontend on
-  port 8080 and proxies `/api/` and `/.well-known/healthcheck` to the backend,
-  which listens on `127.0.0.1:8081` in the same container; the new
-  `BIND_ADDRESS` setting sets its listen address. `bin/entrypoint.sh` starts
-  both, passes TERM and INT on to both, and exits non-zero when either exits on
-  its own. The backend runs as user `netwatch` and stores reports on the `/data`
-  volume. `script/docker` is the org model again
-- 2026-09-28: unified the gate (issue #16): the root `make check` covers the Go
-  backend as well as the frontend, and the pre-commit hook with it; the backend
-  moved onto scripts-to-rule-them-all (`backend/script/*`, `backend/Makefile` as
-  shims, its duplicate hook installer removed); `script/cibuild` builds both
-  images and is the workflow's only build step. The root `make lint` runs
-  golangci-lint only in Docker, by building the lint stage of
-  `Dockerfile.backend` without the cache. `script/bootstrap` installs the pinned
-  Go unless the installed one is at least what `backend/go.mod` asks for, links
-  what it installs into `~/.local/bin` without replacing anything it did not
-  create, and installs no linter. Root `make test` runs both halves within one
-  30-second timeout. When `VERSION` is unset or empty, the backend binary's
-  version falls back to `git describe` inside a git checkout, then to `dev`
-- 2026-09-28: frontend reporting client (issue #53): a `Reporter` class posts
-  collected samples to `/api/v1/reports` every `reportInterval` (default 60s) as
-  a per-host delta, with the report-building step a pure exported function of
-  host state; a per-host mark advances only on a delivered POST; at most one
-  report POST is pending at a time and it is abandoned after half the interval,
-  so a slow POST never overlaps the next report and a mark never moves
-  backwards; the samples of an abandoned POST are sent again at the next
-  interval, so a backend that stored them but answered late receives them twice;
-  the per-browser client id works in insecure (plain-HTTP) contexts;
-  `vite.config.js` proxies `/api` to the local backend for `yarn dev`
-- 2026-09-28: report ingest correctness (issue #23): a storage failure now
-  returns 500 instead of a false `ok`; oversize bodies return 413 (distinguished
-  from malformed JSON, which stays 400); a `MaxBodyBytes` middleware caps every
-  route, not just the report route; the raw attacker-controlled `geo` blob is no
-  longer logged (only its length), and `client_id`, `timestamp` and decode error
-  text are length-bounded before logging; a `decodeJSON` handler helper was
-  added; panic recovery now routes the stack through slog instead of chi's
-  plain-text stderr; and writing a report file now returns its error, so a
-  failed final flush on shutdown makes the process exit non-zero instead of
-  losing the buffered reports silently
-- 2026-09-21: shutdown lifecycle correctness. The process now shuts down through
-  fx instead of `os.Exit`, so every component's `OnStop` runs and buffered
-  reports are flushed to disk on `SIGTERM` — previously a full flush window of
-  telemetry was silently lost on every restart. The `http.Server` is now built
-  before its serving goroutine starts, so shutdown can no longer race or
-  nil-deref it; a listen failure exits non-zero via `fx.Shutdowner`; `reportbuf`
-  `OnStop` is idempotent; and `writeTimeout` now exceeds the chi per-request
-  budget so that budget is actually reachable. Dead `startupTime`, `exitCode`,
-  and `cancelFunc` fields were removed
-- 2026-09-21: backend HTTP hardening (issue #19): added `ReadHeaderTimeout` and
-  `IdleTimeout` to the server, a `SecurityHeaders` middleware (HSTS, tight CSP,
-  frame/sniff/referrer/permissions headers) registered before CORS, and
-  trusted-proxy client IP resolution honouring `X-Forwarded-For` / `X-Real-IP`
-  only from a `TRUSTED_PROXIES` allowlist (loopback plus RFC1918 by default)
-- 2026-08-10: adopted the org-standard `backend/.golangci.yml` verbatim and
-  moved the pinned golangci-lint from v2.7.2 to v2.12.2 (the `lint` stage of
-  `Dockerfile.backend` now pins the `golangci/golangci-lint:v2.12.2` image by
-  digest); the previous config declared `version: "2"` but used v1 schema keys,
-  so every threshold in it was inert and its green result was meaningless.
-  `backend/Makefile`'s `lint` target now asserts the config's sha256 against the
-  canonical file first, so drift from the org standard fails the build instead
-  of silently degrading to defaults
-- 2026-08-10: every interactive control now meets the 44x44 CSS px minimum tap
-  target (`.pin-btn`, `#interval-select`, the debug-log label and, on narrow
-  viewports, `#pause-btn`). The pin button's hit area grows via matching
-  negative margins, so its layout footprint and row density are unchanged
-- 2026-08-10: per-host status line wraps below the 768px breakpoint instead of
-  forcing horizontal page scroll at 320px
-- 2026-08-09: `Dockerfile.backend` reworked to the mandated Go multistage
-  lint-stage pattern: separate `lint` stage on the hash-pinned
-  `golangci/golangci-lint` image, `COPY --from=lint` stage dependency,
-  `CGO_ENABLED=0` static build driven by `ARG VERSION`, and no more `COPY .git`
-- 2026-08-09: dotfile compliance — lifted `backend/.editorconfig` to the repo
-  root so `root = true` covers the frontend too, and replaced `.gitignore` with
-  the org model (OS, editor, node, and environment/secrets sections) plus this
-  repo's `dist/` and `*.log`. `.env`, `.env.*`, `*.pem`, and `*.key` are now
-  ignored repo-wide, not just under `backend/`. Excluding `.git` from
-  `.dockerignore` stays deferred: both images read git metadata at build time
-  (`COPY .git` in `Dockerfile.backend`, `git rev-parse` in `vite.config.js`)
-- 2026-08-09: automated responsive-layout harness
-  (`make frontend-viewport-test`): digest-pinned headless Chrome driven over CDP
-  against the built `dist/`, viewport widths derived from the breakpoints in
-  `src/styles.css` ([#13](https://git.eeqj.de/sneak/netwatch/issues/13)). The
-  tap-target and host-row checks each fail when they measured nothing; the
-  overflow, viewport-edge and clipped-text checks have no such guard of their
-  own and rely on the `app-rendered` check, which fails the run when the app did
-  not render. Found two real layout defects, filed as
-  [#42](https://git.eeqj.de/sneak/netwatch/issues/42) and
-  [#43](https://git.eeqj.de/sneak/netwatch/issues/43)
-- 2026-07-07 Adopted scripts-to-rule-them-all: `script/` entrypoints, Makefile
-  shims, README Entrypoints section
-- 2026-02-27: backend with buffered zstd-compressed report storage; CI workflow
-  and backend repo standard files; backend Dockerfile fixed (Go 1.25,
-  golangci-lint) and moved to repo root (feat/reportbuf-storage)
-- 2026-02-26: host row layout redesigned with CSS grid; overflow and spacing
-  fixes; nginx config extracted; port hardcoded to 8080
-- 2026-02-26: debug log panel, median stats, recovery probe, Docker build fix,
-  S3 Singapore endpoint added
-- 2026-02-23: summary box redesign, host pinning, local and UTC clocks, checks
-  counter
-- 2026-02-23: hosts sorted by latency; GET instead of HEAD for latency; timeout
-  derived from interval; Hetzner regional endpoints; 3s interval
-- 2026-01-29: initial NetWatch network latency monitor
-
 # Future Steps
 
 - A backend test that posts a report to `POST /api/v1/reports` and checks the

configs/security-headers.conf

@@ -8,10 +8,9 @@ add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" alway
 # Scripts and styles load only from the page's own origin. Inline ones
 # are blocked, style attributes in markup included, so style elements
 # through classes or element.style. data: images are for the favicon
-# in web/index.html. connect-src is * because the browser checks each
-# probe in web/src/main.js against it, and also every redirect the probe
-# follows, and several of those hosts redirect to others; a list of
-# hosts here would block those probes. It also covers the reports the
+# in web/index.html. connect-src is * because the page checks every
+# target in web/src/main.js. A list of hosts here would have to change
+# with every change to those targets. It also covers the reports the
 # page sends to its own origin.
 add_header Content-Security-Policy "default-src 'self'; connect-src *; img-src 'self' data:; object-src 'none'; base-uri 'none'; form-action 'none'; frame-ancestors 'none'" always;
 

script/frontend-test

@@ -15,13 +15,13 @@ ROOT="$(cd "$(dirname "$0")/.." && pwd -P)"
 main() {
     cd "$ROOT"
     NODE_OPTIONS=--test-reporter=dot \
-        timeout 90 "$ROOT/script/yarn" --silent run test || {
+        "$ROOT/script/yarn" --silent run test || {
         echo "--- Rerunning with every test listed for details ---"
         NODE_OPTIONS=--test-reporter=spec \
-            timeout 90 "$ROOT/script/yarn" --silent run test
+            "$ROOT/script/yarn" --silent run test
         exit 1
     }
-    timeout 30 "$ROOT/script/yarn" build
+    "$ROOT/script/yarn" build
 }
 
 main "$@"

script/frontend-viewport-test

@@ -31,8 +31,8 @@ HARNESS="netwatch-viewport-harness-$RUN_ID"
 ARTIFACT_DIR="$ROOT/tmp/viewport"
 
 # Every container is named and removed here, including the harness itself:
-# `timeout` below kills the `docker run` client, not the container it
-# started, and an unnamed survivor keeps the --internal network in use so
+# a `docker run` client that is killed outright leaves its container
+# running, and an unnamed survivor keeps the --internal network in use so
 # `docker network rm` fails too. This host runs many sessions at once and
 # neither may be left behind.
 cleanup() {
@@ -122,7 +122,7 @@ main() {
         -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' \
         "$BROWSER")"
 
-    timeout 900 docker run --rm --init --name "$HARNESS" \
+    docker run --rm --init --name "$HARNESS" \
         --network "$NETWORK" \
         --user "$(id -u):$(id -g)" \
         -v "$ROOT:/app" \

test/unit/main.test.js

@@ -180,6 +180,91 @@ test("a check fetches the target's URL as written, with no query string added",
     );
 });
 
+test("a check sends no Referer header, wherever the page is served from", async (t) => {
+    mockTargets(t, () => 10);
+    const check = measureLatency("https://fsn1-speed.hetzner.com");
+    t.mock.timers.tick(10);
+    assert.notEqual(await settled(check), "still waiting");
+    assert.equal(
+        fetch.mock.calls[0].arguments[1].referrerPolicy,
+        "no-referrer",
+    );
+});
+
+// These targets' home pages answer with a redirect. A check follows it and
+// times the request to the new URL too, often on another host. The Google
+// Cloud Console redirects only requests that do not say they come from
+// another site, such as curl's. Each target is checked at /robots.txt on
+// its own host, which answers without a redirect. An S3 region answers it
+// with 403, and any answer counts as reachable.
+test("a target whose home page redirects is checked at /robots.txt on its own host", () => {
+    const checked = new Map(
+        new AppState([]).wan.map((host) => [host.name, host.url]),
+    );
+    for (const [name, url] of [
+        ["AWS Console", "https://console.aws.amazon.com/robots.txt"],
+        ["Google Cloud Console", "https://console.cloud.google.com/robots.txt"],
+        ["Akamai", "https://www.akamai.com/robots.txt"],
+        ["B2", "https://api.backblazeb2.com/robots.txt"],
+        [
+            "S3 af-south-1 (Cape Town)",
+            "https://s3.af-south-1.amazonaws.com/robots.txt",
+        ],
+        [
+            "S3 eu-west-2 (London)",
+            "https://s3.eu-west-2.amazonaws.com/robots.txt",
+        ],
+        [
+            "S3 me-south-1 (Bahrain)",
+            "https://s3.me-south-1.amazonaws.com/robots.txt",
+        ],
+        [
+            "S3 ap-northeast-1 (Tokyo)",
+            "https://s3.ap-northeast-1.amazonaws.com/robots.txt",
+        ],
+        [
+            "S3 ap-southeast-1 (Singapore)",
+            "https://s3.ap-southeast-1.amazonaws.com/robots.txt",
+        ],
+        [
+            "S3 ap-southeast-2 (Sydney)",
+            "https://s3.ap-southeast-2.amazonaws.com/robots.txt",
+        ],
+        [
+            "S3 us-west-2 (Oregon)",
+            "https://s3.us-west-2.amazonaws.com/robots.txt",
+        ],
+        [
+            "S3 sa-east-1 (São Paulo)",
+            "https://s3.sa-east-1.amazonaws.com/robots.txt",
+        ],
+    ]) {
+        assert.equal(checked.get(name), url);
+    }
+});
+
+// Chrome keeps the connection to an S3 region open after a HEAD check, but
+// closes it after most GET checks. The Hetzner servers do not answer HEAD.
+test("a round checks each S3 region with a HEAD request and every other target with a GET request", async (t) => {
+    const state = new AppState([
+        { name: "Local CPE", url: "http://192.168.100.1" },
+    ]);
+    mockTargets(t, () => 10);
+    const round = tick(state, new AbortController().signal);
+    t.mock.timers.tick(10);
+    assert.notEqual(await settled(round), "still waiting");
+    const methods = new Map(
+        fetch.mock.calls.map((call) => [
+            call.arguments[0],
+            call.arguments[1].method,
+        ]),
+    );
+    for (const host of state.allHosts) {
+        const method = host.name.startsWith("S3 ") ? "HEAD" : "GET";
+        assert.equal(methods.get(host.url), method, host.name);
+    }
+});
+
 test("at a 30000ms interval, a target answering after 1000ms shows in its row while another target's check is still waiting", async (t) => {
     CONFIG.updateInterval = 30000;
     const state = new AppState([

test/viewport/README.md

@@ -1,114 +1,146 @@
-# Responsive-layout harness
+# The viewport test
 
-Automated verification of the responsive layout that landed in #5. Run it with:
+`make frontend-viewport-test` checks the page's layout at several window widths
+in a real browser:
 
 ```bash
 make frontend-viewport-test
 ```
 
-It builds `dist/`, serves it from the same digest-pinned `nginx` image and the
-same `configs/nginx.conf` the shipping container uses, drives a digest-pinned
-headless Chrome against it over CDP, and asserts on computed layout at every
-viewport width derived from the app's own CSS. Screenshots land in
-`tmp/viewport/` alongside a `results.json`; they are artifacts for a human to
-look at when something fails, not the evidence. The assertions are the evidence.
+First it runs the unit tests. Then it builds the page into `dist/`. It serves
+`dist/` with the nginx image and the `configs/nginx.conf` that the Docker image
+ships. Before the browser starts, it fetches `/` and `/no-such-page`, which
+nginx answers with the page. Both must carry `Cache-Control: no-cache` and a
+`Content-Security-Policy` header. Then it starts a headless Chrome in a
+container and opens the page in it at each width. For each width it measures the
+layout inside the page and checks the measurements in Node. The checks decide
+pass or fail. Screenshots and a `results.json` land in `tmp/viewport/`, for a
+person to look at when a check fails.
 
-The target is deliberately outside `make check`: it takes minutes, and
-`make test` has to stay under 60 seconds.
+The test is not part of `make check`: it takes minutes, and `make test` has to
+finish in under 60 seconds.
 
-## How the widths are chosen
+## The widths
 
-Not from a list of phone models. `viewports.js` parses the `@media` conditions
-out of `web/src/styles.css` and scans `web/src/main.js` and `web/index.html` for
-Tailwind responsive prefixes, then tests every breakpoint it finds at one pixel
-below it, exactly on it, and one pixel above it. A generic 375px "phone" test
-sails straight past an off-by-one at a media query boundary; `max-width: 768px`
-matches _at_ 768, and the sweep pins down which side of that line each layout is
-on.
+The breakpoints are read from the page's own files. `viewports.js` reads the
+`min-width` and `max-width` conditions out of the `@media` blocks in
+`web/src/styles.css`. It also looks in `web/src/main.js` and `web/index.html`
+for Tailwind's responsive class prefixes, such as `md:`, and takes their
+breakpoints. Each breakpoint is tested at one pixel below it, exactly on it, and
+one pixel above it. Today the CSS has one breakpoint, `max-width: 768px`, and no
+responsive prefix is used.
 
-Nothing hardcodes 768. Add a second media block or start using `md:` classes and
-the new breakpoint is covered without this directory being touched. The app is
-desktop-first today (all narrow rules live in `max-width` blocks); a
-`min-width`-only, mobile-first set is handled as its inverse, and a set that
-mixes the two makes the run fail loudly rather than test the right widths with
-the wrong expectation. Four further viewports are fixed anchors, each with a
-stated reason: a 320px floor, a 1280px desktop baseline, and two phone-landscape
-sizes straddling the breakpoint for the rotation case.
+A `max-width: 768px` block matches at 768 pixels. Testing both sides of each
+breakpoint catches a layout that switches one pixel too early or too late. A
+second media block, or a first `md:` class, is covered without a change to this
+directory.
 
-## What it asserts
+The page is desktop-first: the wide layout is the default, and every narrow rule
+is in a `max-width` block. So a width is expected to show the narrow layout when
+one of those blocks matches it. A page with only `min-width` blocks would be
+read the other way round. A page that mixes the two kinds fails the run with a
+message, because the right expectation for each width can no longer be read from
+the breakpoints alone.
 
-- **app-rendered** — enough host rows exist and enough of them show a numeric
-  latency. This one exists so the rest cannot pass vacuously against a blank
-  page.
-- **no-horizontal-overflow** — `documentElement.scrollWidth` fits the layout
-  viewport, with the widest offending element named.
-- **nothing-past-viewport-edge** — no visible element's box extends past the
-  viewport edge.
-- **no-clipped-text** — nothing hides text behind `overflow: hidden`. Deliberate
-  ellipsis truncation (Tailwind's `truncate`, used on host names and URLs) is
-  excluded: it is a design choice, not breakage.
-- **tap-targets-44px** — every interactive control is at least 44x44 CSS px on
-  touch viewports, _and_ each selector in the control list matched at least the
-  number of visible elements it declares: one of each single control, and one
-  pin button per WAN host row. The second half is what stops the check passing
-  vacuously: with size alone, a renamed class would take its controls out of the
-  measured set and the check would report "all 0 controls are at least 44x44"
-  and pass. See below.
-- **host-rows-stacked / host-rows-side-by-side** — the rows genuinely reflow.
-  Computed `flex-direction` _and_ the actual geometry are checked, and in the
-  narrow layout the info block and the sparkline must each occupy essentially
-  the full row width. A row that merely shrank its 420px column would fail.
-- **probing-still-runs / gateway-detection-still-runs** — narrow viewports keep
-  probing and keep detecting the gateway. The mobile early-return path proposed
-  in #8 was rejected; this is what would catch it coming back.
+Four more widths are fixed, each for a stated reason:
 
-### The tap-target threshold
+- 320 by 568 pixels: the narrowest width still in common use
+- 667 by 375 pixels: a phone in landscape, inside the narrow layout
+- 844 by 390 pixels: a large phone in landscape, in the wide layout but still a
+  touch device
+- 1280 by 800 pixels: a desktop window
 
-44x44 CSS px. That is the figure in Apple's Human Interface Guidelines and in
-WCAG 2.2 SC 2.5.5 "Target Size (Enhanced)". WCAG 2.2 SC 2.5.8 (level AA) sets a
-lower 24x24 floor, but that floor comes with a spacing exception these controls
-do not qualify for — the pin buttons sit directly against the host name they
-belong to.
+Every width but 1280 by 800 is tested as a touch device.
 
-## Determinism
+## The checks
 
-The browser container runs on an `--internal` docker network and has no route to
-the internet, so the app's latency probes cannot reach anything real. The
-harness answers them itself from a fixed delay table, with a deterministic
-fraction failed outright, so the rows render a realistic spread of one-, two-
-and three-digit latencies plus some unreachable rows. That spread is what the
-layout has to survive; a `---` placeholder in every row would not exercise it.
+A failed check does not stop the others.
 
-## What this cannot verify
+- `app-rendered`: at least 10 WAN host rows exist, and at least 5 rows show a
+  number as their latency. Without this, the other checks could pass against a
+  blank page.
+- `no-horizontal-overflow`: the document is no wider than the window. On a
+  failure, the widest content is named.
+- `nothing-past-viewport-edge`: no visible element extends past the window's
+  edge.
+- `no-clipped-text`: no element hides its text behind `overflow: hidden` or
+  `overflow: clip`. Text cut with an ellipsis is allowed: that cut is a design
+  choice, not a defect. Tailwind's `truncate` cuts host names and URLs that way.
+- `tap-targets-44px`, on touch widths: each measured control is at least 44 by
+  44 CSS pixels. The controls are `#pause-btn`, `#interval-select`,
+  `#debug-toggle` and the `.pin-btn` in each WAN host row. The check also
+  demands that each selector matches enough visible elements: one of each single
+  control, and one pin button per WAN host row. A renamed class would otherwise
+  take its controls out of the measured set, and the check would pass on
+  nothing.
+- `host-rows-stacked` or `host-rows-side-by-side`: each host row shows the
+  layout expected at that width. In the narrow layout, the row's
+  `flex-direction` is `column`, the graph sits below the host's details, and
+  each takes at least 90% of the row's width. In the wide layout, the direction
+  is `row` and the graph sits to the right of the details. A row that only
+  shrank its fixed 420-pixel column fails.
+- `probing-still-runs`: the page sent at least one check to a target at this
+  width. The narrow layout must not skip the checks.
+- `gateway-detection-still-runs`: the `Local Gateway` row is present at this
+  width, so the gateway was looked for and found. The narrow layout must not
+  skip that search.
 
-Real limits, so nobody re-parks this issue as needing hardware:
+### The tap-target size
 
-- **Non-Chromium engines.** This is Chrome. iOS Safari is WebKit and cannot be
-  emulated by it; Safari-specific bugs (viewport units under a collapsing URL
-  bar, `-webkit-fill-available`, form control metrics) will not show up here.
-- **Real touch input.** `hasTouch` emulation changes what the page is told, not
-  how a finger behaves. Gesture handling, scroll momentum, double-tap zoom and
-  hover-state fallbacks on touch are out of scope.
-- **Physical pixel density and rendering.** `deviceScaleFactor` is set, but
-  subpixel antialiasing, OLED colour rendering and actual legibility at a given
-  physical size are not measurable here.
-- **Fonts.** The container has DejaVu, not the platform's own UI monospace. Text
-  metrics are therefore close to, but not identical to, a real device — a layout
-  that fits here by a few pixels might not there.
-- **On-device performance.** Canvas sparkline redraw cost, battery, and
-  behaviour on a slow radio are not measured.
-- **Browser chrome.** The address bar, safe-area insets and notch cutouts are
-  not simulated.
+44 by 44 CSS pixels is the figure in Apple's Human Interface Guidelines and in
+WCAG 2.2 success criterion 2.5.5, "Target Size (Enhanced)". WCAG 2.2 criterion
+2.5.8 sets a lower minimum of 24 by 24 pixels, with an exception that depends on
+the space around a control. The pin buttons sit against the host name they
+belong to, so the test keeps 44.
 
-Everything else this issue was actually about — does the layout reflow, does
-anything overflow, is content clipped, are the controls big enough — is a
-function of viewport width and CSS, and is covered above.
+## The browser's network
+
+The browser container runs on an internal Docker network with no route to the
+internet, so the page's checks reach no real host. The test answers them itself
+from a fixed table of delays: 2, 45, 123, 456 and 780 milliseconds. Which delay
+a target gets depends on its URL, and about one target in seven fails outright.
+So the rows show one-, two- and three-digit latencies and some unreachable rows,
+and the layout is tested against that spread. The request to
+`http://192.168.1.1` is answered after 5 milliseconds, so the `Local Gateway`
+row appears.
+
+At each width, the test sets the interval to 1 second and waits until at least 5
+rows show a latency before it measures. The page discards its first round, so
+this reaches a filled page without waiting out two rounds at 3 seconds.
+
+## What the test cannot check
+
+- Other browser engines. The test runs Chrome. Safari uses WebKit, and bugs that
+  only WebKit has do not show up here.
+- Real touch input. Touch emulation changes what the page is told, not how a
+  finger behaves. Gestures, scroll momentum, double-tap zoom and hover states on
+  touch are not tested.
+- Physical pixels. The device pixel ratio is set, but antialiasing, colour
+  rendering and legibility at a given physical size are not measured.
+- Fonts. The container has DejaVu, not a phone's own monospace font. Text is
+  about as wide as on a real device, but not exactly. A layout that fits here by
+  a few pixels might not fit there.
+- Performance. The cost of redrawing the graphs, battery use and behaviour on a
+  slow connection are not measured.
+- The browser's own frame. The address bar, safe-area insets and notch cutouts
+  are not simulated.
+
+## The files
+
+- `viewports.js` derives the widths from the sources.
+- `facts.js` is run inside the page and measures the layout. It only measures;
+  it decides nothing.
+- `checks.js` turns the measurements into the pass or fail of each check, with
+  the numbers that decided it.
+- `harness.js` connects to the browser, runs each width, writes the screenshots
+  and `results.json`, and prints the results. `script/frontend-viewport-test`
+  starts it; every input it needs arrives in the environment.
 
 ## Relation to the unit tests
 
-Complementary layers, not two stacks. The unit tests in `test/unit/`, which
-`make test` runs with Node's built-in test runner, exercise the functions
-`web/src/main.js` exports in-process with no browser. This harness exercises
-rendered layout in a real engine and is the only thing here that can see a media
-query. Neither replaces the other; assertions about computed styles and element
-geometry belong here, assertions about functions belong in `test/unit/`.
+The unit tests in `test/unit/` call the functions that `web/src/main.js`
+exports, with no browser. `make test` runs them with Node's built-in test
+runner. This test runs the built page in a real browser engine and is the only
+test here that can see a media query. Neither replaces the other. Checks on
+computed styles and element geometry belong here; checks on functions belong in
+`test/unit/`.

web/src/main.js

@@ -67,51 +67,66 @@ export const CONFIG = {
 
 // WAN endpoints to monitor. These are used for the aggregate health/stats
 // display (min/max/avg). Ordered: personal, LLM APIs, big-3 cloud, then
-// CDN/hosting/other.
+// CDN/hosting/other. A check follows a redirect and times the request to
+// the new URL too. So a target whose home page redirects is checked at
+// /robots.txt on its own host. That URL answers without a redirect.
 const WAN_HOSTS = [
     { name: "datavi.be", url: "https://datavi.be" },
     { name: "Anthropic API", url: "https://api.anthropic.com" },
     { name: "OpenAI API", url: "https://api.openai.com" },
-    { name: "AWS Console", url: "https://console.aws.amazon.com" },
-    { name: "Google Cloud Console", url: "https://console.cloud.google.com" },
+    { name: "AWS Console", url: "https://console.aws.amazon.com/robots.txt" },
+    {
+        name: "Google Cloud Console",
+        url: "https://console.cloud.google.com/robots.txt",
+    },
     { name: "Microsoft Azure", url: "https://portal.azure.com" },
     { name: "Cloudflare", url: "https://www.cloudflare.com" },
     { name: "Fastly CDN", url: "https://www.fastly.com" },
-    { name: "Akamai", url: "https://www.akamai.com" },
+    { name: "Akamai", url: "https://www.akamai.com/robots.txt" },
     { name: "Google", url: "https://www.google.com" },
     { name: "GitHub", url: "https://github.com" },
-    { name: "B2", url: "https://api.backblazeb2.com" },
+    { name: "B2", url: "https://api.backblazeb2.com/robots.txt" },
+    // Chrome keeps the connection to an S3 region open after a HEAD check,
+    // but closes it after most GET checks.
     {
         name: "S3 af-south-1 (Cape Town)",
-        url: "https://s3.af-south-1.amazonaws.com",
+        url: "https://s3.af-south-1.amazonaws.com/robots.txt",
+        method: "HEAD",
     },
     {
         name: "S3 eu-west-2 (London)",
-        url: "https://s3.eu-west-2.amazonaws.com",
+        url: "https://s3.eu-west-2.amazonaws.com/robots.txt",
+        method: "HEAD",
     },
     {
         name: "S3 me-south-1 (Bahrain)",
-        url: "https://s3.me-south-1.amazonaws.com",
+        url: "https://s3.me-south-1.amazonaws.com/robots.txt",
+        method: "HEAD",
     },
     {
         name: "S3 ap-northeast-1 (Tokyo)",
-        url: "https://s3.ap-northeast-1.amazonaws.com",
+        url: "https://s3.ap-northeast-1.amazonaws.com/robots.txt",
+        method: "HEAD",
     },
     {
         name: "S3 ap-southeast-1 (Singapore)",
-        url: "https://s3.ap-southeast-1.amazonaws.com",
+        url: "https://s3.ap-southeast-1.amazonaws.com/robots.txt",
+        method: "HEAD",
     },
     {
         name: "S3 ap-southeast-2 (Sydney)",
-        url: "https://s3.ap-southeast-2.amazonaws.com",
+        url: "https://s3.ap-southeast-2.amazonaws.com/robots.txt",
+        method: "HEAD",
     },
     {
         name: "S3 us-west-2 (Oregon)",
-        url: "https://s3.us-west-2.amazonaws.com",
+        url: "https://s3.us-west-2.amazonaws.com/robots.txt",
+        method: "HEAD",
     },
     {
         name: "S3 sa-east-1 (São Paulo)",
-        url: "https://s3.sa-east-1.amazonaws.com",
+        url: "https://s3.sa-east-1.amazonaws.com/robots.txt",
+        method: "HEAD",
     },
     // Hetzner regional speed test servers — genuine per-DC endpoints
     {
@@ -271,6 +286,7 @@ export class HostState {
     constructor(host, pinned = false) {
         this.name = host.name;
         this.url = host.url;
+        this.method = host.method;
         // Each entry is either a check's result, { timestamp, latency,
         // error }, or a round skipped while paused, { timestamp,
         // latency: null, paused: true }.
@@ -567,16 +583,18 @@ export class Reporter {
 
 // --- Latency Measurement -----------------------------------------------------
 
-// Checks one target. The check times out after CONFIG.requestTimeout; the
-// caller can give it up sooner through the optional signal, which also ends
-// it as a timeout. A failed check's reason says what went wrong and after
-// how long; a check that answered has none.
+// Checks one target with the given HTTP method, GET when none is given. The
+// check times out after CONFIG.requestTimeout; the caller can give it up
+// sooner through the optional signal, which also ends it as a timeout. A
+// failed check's reason says what went wrong and after how long; a check
+// that answered has none.
 //
-// The URL is fetched as written, with nothing added to it: the Hetzner
-// speed-test servers close the connection without an answer when the URL
-// has a query string, and cache: "no-store" keeps the browser's cache out
-// of the measurement.
-export async function measureLatency(url, signal) {
+// The Hetzner speed-test servers close the connection without an answer
+// when the URL has a query string or the request has a Referer header. So
+// the URL is fetched as written, and referrerPolicy: "no-referrer" sends
+// no Referer header, wherever the page is served from. cache: "no-store"
+// keeps the browser's cache out of the measurement.
+export async function measureLatency(url, signal, method = "GET") {
     const controller = new AbortController();
     const timeoutId = setTimeout(
         () => controller.abort(),
@@ -588,9 +606,10 @@ export async function measureLatency(url, signal) {
 
     try {
         await fetch(url, {
-            method: "GET",
+            method,
             mode: "no-cors",
             cache: "no-store",
+            referrerPolicy: "no-referrer",
             signal: controller.signal,
         });
         const latency = Math.round(performance.now() - start);
@@ -905,7 +924,7 @@ export function buildUI(state) {
       </div>
 
       <footer class="mt-8 text-center text-gray-600 text-xs">
-        <p>Latency measured via GET requests | CORS restrictions may affect some measurements</p>
+        <p>Latency: the time until a target's response headers arrive</p>
         <p class="mt-2">
           <span class="inline-block w-3 h-3 rounded-full bg-green-500 mr-1 align-middle"></span>&lt;50ms
           <span class="inline-block w-3 h-3 rounded-full bg-lime-500 mr-1 ml-3 align-middle"></span>&lt;100ms
@@ -1290,7 +1309,7 @@ export async function tick(state, signal, onOffline) {
     // the round started.
     await Promise.all(
         state.allHosts.map(async (host) => {
-            const r = await measureLatency(host.url, signal);
+            const r = await measureLatency(host.url, signal, host.method);
             if (state.paused || signal.aborted || state.tickCount === 0) {
                 return;
             }
@@ -1363,7 +1382,7 @@ function startRecoveryProbe(state, startRounds) {
         const checks = new AbortController();
         state._recoveryProbeChecks = checks;
         for (const host of canaries) {
-            measureLatency(host.url, checks.signal).then((r) => {
+            measureLatency(host.url, checks.signal, host.method).then((r) => {
                 if (r.error !== null || checks.signal.aborted) return;
                 log.notice("Recovery probe: connectivity detected");
                 stopRecoveryProbe(state);