Essay · XB Field Notes

Readable evidence before dashboards

Tue, 18 Aug 2026 00:00:00 +0000

Monitoring dashboards are convenient, but convenience is not the same as evidence. This essay argues that for a small static service, the most auditable form of “is the site healthy?” is a set of plain-text facts an operator can read, re-run, and paste into a report — not an aggregated panel.

The distinction matters because the two answer different questions. A dashboard is a lens over many samples, tuned to alert you to trends. A probe is a single, reproducible observation of the public edge. When the job is to prove a release or diagnose a specific request, the probe is the higher-fidelity artifact.

The dashboard’s aggregation is the risk

A dashboard turns thousands of raw observations into a series of aggregated panels: average latency, error rate, uptime percentage. Aggregation is where the audit trail thins. An “uptime 99.98%” figure does not tell you which request failed, which header was wrong, or whether today’s release is the one being served. It is a summary that erases the evidence that produced it unless you keep the raw log elsewhere.

For a confidence property like “the edge serves the tree I staged”, a dashboard is the wrong tool. That property is answered by a single deterministic observation, and a terminal command can answer it exactly once.

A probe you can read

The site ships a small read-only helper, downloads/check-http-headers.sh, that prints the served response in plain text:

HTTP/2 200
content-type: text/html; charset=utf-8
content-security-policy: default-src 'self'; …; script-src 'none'; …

A human reads this line and knows three things at once: the status is 200, the type is HTML, and the no-script policy is actually being served. Compare that to a panel that says “edge OK” — the panel requires trust in whatever computed it; the header line is itself the evidence. The certificate is judged the same way, by reading notAfter as a date rather than a color in a panel.

Replace signal loss with a checkable statement

The mechanism the site favors instead of a dashboard is a contract enforced during build and a set of deterministic commands for the release window. Roughly:

Offline checks validate the artifact (every internal link, every SVG, the no-script boundary, the checksums).
A single read-only probe against the public edge confirms status, headers, and certificate in one invocation.
A byte manifest ties the served tree to the staged tree so “agrees with what we staged” is a hash, not a feeling.

Each of these is a sentence an operator can paste into an issue or a changelog and a future auditor can re-run. None of them requires a panel to be understood.

When you genuinely need a dashboard

None of this says observability is pointless. If you operate many instances, aggregate capacity, or long trends, a dashboard is the right view to see the forest. The claim is narrower: when the question is “is this one release healthy at the public edge”, the answer lives in a reproducible terminal read, and bolting a panel on top adds latency and aggregation loss without adding evidence.

The decision heuristic is simple. If a statement can be checked with one command and its output is the proof, prefer the command and keep dashboard only where you genuinely need the aggregate. That keeps the site’s own operational story as auditable as the site’s content.

Sources

Curl documentation, reading response headers from a single invocation, checked 2026-08-18.
Twelve-Factor: Logs, treating logs as event streams an operator can read, checked 2026-08-18.
OpenTelemetry: Observability primer, observability as high-cardinality, contextual output, checked 2026-08-18.

Cache validation is two clocks, not one freshness setting

Fri, 14 Aug 2026 00:00:00 +0000

Caching is the easiest place to introduce a silent correctness bug, because a cache looks correct right up until it serves bytes that do not match the origin. The mental model that keeps this straight treats every cache as decoding two independent clocks instead of one expiry value.

A conditional request carries two kinds of information, and conflating them is how stale content ships. One clock is freshness — how long a response may be reused without asking. The other is validation — how a client asks whether its copy is still current. This essay reads both clocks through this site’s live response and shows what each one is actually for.

Freshness: how long to trust a byte without asking

Freshness is the clock that decides whether a request is served from the cache at all. It is normally expressed as Cache-Control (max-age) or an Expires date. Within the freshness window, a cache returns the stored response and never contacts the origin. Its job is to reduce latency and origin load; its cost is that it can serve a version slightly behind the origin within the window.

For a static site the freshness window and the immutable artifact agree: a deploy replaces the whole tree, so a short freshness plus a validator is a safe, boring default. The important thing is that freshness alone cannot detect stale content after the window expires — that is the second clock’s job.

Validation: how a client asks “is it still current?”

When freshness expires, the client does not necessarily re-download the whole resource. Validation is the conditional request: send the stored identifier, and the origin replies either with the new representation or with a status saying the stored copy is still current. The two identifiers HTTP defines are the ETag (an opaque validator, typically derived from entity bytes) and Last-Modified (a timestamp validator).

The live response of this site shows both clocks concretely:

etag: "dkx84jwth7nkc9e"
last-modified: Mon, 24 Aug 2026 00:00:00 GMT

A conditional If-None-Match request against that ETag yields a 304 Not Modified — the validators agree, so the client reuses the cached copy without re-downloading the body. This is the second clock doing its job: a cheap round trip, not a full transfer.

Why freshness and validation are independent

The two clocks must be understood separately because one does not imply the other. A response can be freshly cached and need no validation, yet the validation identifiers still matter for the moment freshness lapses. Conversely you can have strong validators but a freshness policy that causes needless revalidation for resources that barely change. For a static file the two are easy to set coherently: a short or public freshness, a strong ETag from the artifact bytes, and a revalidation path the client uses the moment freshness passes.

The failure mode to watch is collapsing both into “the cache expired, so re-download”. That ignores validators and turns every expiry into a full transfer. The compressed artifact makes the round trip small — this page’s HTML transfers as a few kilobytes — but the principle (the validators principle (a cache refuses stale but avoids redundant whole-body transfer) holds regardless of size.

The contract worth asserting

Once you can name freshness and validation separately, a release check can assert them: the served headers include both etag and last-modified; the freshness window is short enough to be honest; and a conditional request returns 304 when the validator matches. Those three checks describe a cache that cannot silently serve indefinitely-old bytes or leak bandwidth. That is a weaker word to prove than dashboard graphs, which is why it belongs in a decision log rather than in a monitoring chart.

Sources

MDN: HTTP caching, expiration and validation as distinct mechanisms, checked 2026-08-14.
MDN: HTTP ETag, conditional request validation, checked 2026-08-14.
RFC 9111: HTTP Caching, cache expiration and validation rules, checked 2026-08-14.

The zero-JavaScript static site is a defensible choice

Thu, 13 Aug 2026 00:00:00 +0000

A static site does not need JavaScript to be defensible; the absence of a <script> tag can itself be the point. This essay argues the engineering case for shipping a site whose script lanes are closed by policy, then proves the claim with the header this publication actually serves.

The argument has three parts: the threat surface you delete, the contract that makes deletion observable, and the cases where deleting the layer is the wrong call.

The threat surface you delete by not having a script lane

A page that executes no own or third-party script removes an entire class of failure and abuse at once. Cross-site scripting lives in a document that can run injected code; a document that cannot run code at all has nothing for an injection to escalate into. Third-party trackers and widgets are gone because there is no script tag to embed them. Supply-chain risk from accidental dependency drift in the browser bundle is gone because there is no bundle. Each of these is a bounded, nameable surface — the small-systems property of choosing boundaries you can articulate.

None of this claims the site is “secure”. It claims the attack surface is narrower and, crucially, easier to reason about because it is enumerated by construction rather than by audit.

The header that makes the boundary enforceable

A taste is not a policy. The difference here is that the no-script contract is enforced by the server, not by developer convention. The live response of this site carries:

content-security-policy: default-src 'self'; base-uri 'self'; form-action 'none'; frame-ancestors 'none'; object-src 'none'; script-src 'none'; style-src 'self'; img-src 'self' data:

The script-src 'none' directive is the enforceable part. Even if a future release lets a stray <script> into a page, the browser refuses to execute it. The absence of JavaScript is therefore a served contract, checked by the verifier on every build (script-free), not a hope. This is the difference between saying “we do not use JS” and “the public edge refuses to run JS”.

What the static structure buys after the removal

With no scripting, the content model reverts to something closer to published documents. Caching is simpler because a static file has a stable byte identity and an ETag rather than a mutable DOM. Reading the served HTML in a terminal, using view-source, or indexing the tree is straightforward because the artifact is ordinary files on disk. The trade the site accepts is deliberate: no interactive state, no client-side rendering, no feedback that needs a view model. For a documentation and operations site that is the correct exchange, and it is worth writing down.

When the zero-JS claim is the wrong call

The boundary is a feature, not a badge of purity. A site that genuinely needs client-side interactivity — a realtime dashboard, a document editor, a payment flow — should not contort itself into serving static HTML and then bolting on a workaround. The wrong application of this decision is to shave a product to fit the constraint. The right application is to recognize that content that is read, searched, and archived profits from being a document, and to reserve scripting for where a document is insufficient.

For this property, the served header is the evidence, and it is reproducible on any release by reading the public edge. That is the difference between a preference and a deployed decision.

Sources

MDN: Content Security Policy (script-src), directives that disable script execution, checked 2026-08-13.
PortSwigger: What is cross-site scripting (XSS)?, the attack class removed when scripts cannot run, checked 2026-08-13.
OWASP: Content Security Policy, CSP as a defense-in-depth control, checked 2026-08-13.