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.

A response supports a scoped claim. Repeated observations support trends when the underlying records and their provenance remain inspectable.

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. A response-body comparison can answer that question for one URL, representation, network vantage point, and instant. A homepage header fetch cannot establish the identity of a whole tree or every CDN node.

A probe you can read

The repository ships a small read-only helper, static/downloads/check-http-headers.sh, also published at /downloads/check-http-headers.sh. It prints response headers and the final status/URL. The following is an illustrative excerpt, not a new production measurement:

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

A real capture can directly show the response status, declared media type, and delivered CSP. The abbreviated example above cannot establish a complete no-script policy: inspect the full enforcing header, including any script-src-elem or script-src-attr directives that take precedence for their categories. A Report-Only policy does not block execution. A panel that says “edge OK” should expose the same underlying capture and acceptance criteria. Both still depend on the probe implementation, TLS verification, routing, and retention of the original output. Reading certificate notAfter adds an expiry observation; it does not establish hostname matching or trust-chain validity.

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 repeatable collection steps for the release window. Roughly:

Offline checks validate the artifact (every internal link, every SVG, the no-script boundary, the checksums).
Separate public-edge checks record status/headers, response bytes, and TLS identity/expiry. The header helper does not print certificate dates or automatically reject every unexpected HTTP status.
A byte manifest describes the staged tree; retrieving selected URLs and comparing their bodies establishes sampled delivery parity. A complete claim requires checking all published mappings and representation transformations, not merely hashing the server disk.

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.

Keep enough context to repeat the observation

Record UTC time, requested and final URL, method, selected encoding, resolved remote IP, client version, exit status, HTTP status, relevant headers, and body digest. Preserve failures as well as successes. Redact credentials, cookies, and personal data before sharing logs. A proxy error page returning 200 can pass a status-only check; comparing a known body or release marker catches a different failure mode.

A useful release report distinguishes “this response matched at this time” from “the service met its availability objective over a month.” Retain the raw observations behind aggregate metrics, and make a dashboard link back to them where possible. Neither display format creates trustworthy measurements by itself.

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”, a reproducible terminal read is a good starting point. Repeated probes, several vantage points, error budgets, and alerting add evidence about intermittent or regional failures that a single successful request cannot supply. A well-designed dashboard can expose those observations without hiding their provenance.

The decision heuristic is simple. If a claim can be checked with one command, preserve that command’s output together with its scope and acceptance criteria. Use dashboards where aggregation helps, while retaining access to the underlying evidence. 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-10-15.
Twelve-Factor: Logs, treating logs as event streams an operator can read, checked 2026-10-15.
OpenTelemetry: Observability primer, the complementary roles of logs, metrics, and traces, checked 2026-10-15.
W3C: Content Security Policy Level 3, enforcing versus Report-Only delivery and script directive precedence (working draft), checked 2026-10-18.

Freshness and validation in the two-clock cache model

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

Caching has two separate decisions: may a stored response be reused without contacting the server, and how can the client check whether that response still represents the resource? Calling them “two clocks” is a mnemonic. Freshness really is an age calculation; validation is a comparison, not another timer. A response can be fresh by policy while already differing from a newly deployed origin, without the cache violating HTTP.

Simplified age example: matching variant, no overriding request directive. no-cache still requires validation; must-revalidate forbids unvalidated stale reuse. Validator matching does not prove byte identity.

Freshness: how long to reuse without asking

Cache-Control: max-age=60 gives a response a freshness lifetime of 60 seconds. A cache compares that lifetime with the response’s current age, accounting for Date, Age, transit time, and time stored. At exactly 60 seconds it is stale, not fresh for one more second. Shared caches prefer s-maxage when present; absent explicit freshness, some responses can receive heuristic freshness.

A fresh response is usually reusable, but matching the cache key and Vary fields and obeying request/response directives still matters. no-cache requires successful validation before reuse even when the response could otherwise be fresh. no-store prohibits storage; it is not a synonym for revalidate. public permits shared-cache storage in cases otherwise restricted; it does not specify a duration.

For mutable HTML, a short explicit lifetime plus validation is often useful. It intentionally permits updates to take up to that lifetime to become visible through a compliant cache. A whole-tree deployment does not invalidate existing browser or CDN entries. Content-addressed assets can instead use a long lifetime when the URL changes with the bytes.

Validation: ask whether the stored representation still matches

An ETag is an opaque validator, not a checksum the client should decode. Last-Modified is a timestamp validator. Neither header specifies an explicit freshness lifetime, and a server need not supply both. When heuristic freshness is permitted, however, a cache can use Last-Modified to estimate a lifetime. For example, these illustrative headers express a lifetime and a validator separately:

Cache-Control: max-age=60, must-revalidate
ETag: "release-a"

After expiry, If-None-Match: "release-a" lets a GET receive 304 Not Modified if the selected representation still matches, or a new 200 with a body if it changed. The cache updates applicable metadata from the 304 and reuses its stored body. A 304 is not useful without a corresponding stored representation. If-None-Match uses weak comparison, so successful validation does not necessarily prove byte-for-byte identity; If-Range and combining partial responses have stronger requirements.

The server can compute an ETag from bytes or other reliably changing metadata. A strong tag must distinguish representations whose data differs, including content codings where applicable. Sending the same strong ETag for different gzip and identity bytes is not fixed by adding a short lifetime. Vary: Accept-Encoding also tells a cache which request header affected selection.

A small exercise that separates the decisions

This Python model deliberately excludes heuristic freshness, network delay, and variant selection. age stands for the already calculated current age; the conditional request uses a server validator that has not changed. The model compares two fixed tag strings; it does not implement HTTP entity-tag parsing, tag lists, or the full weak-comparison rules.

lifetime = 60
stored_etag = '"release-a"'
server_etag = '"release-a"'
for age in (59, 60, 61):
 fresh = age < lifetime
 action = "reuse without validation" if fresh else (
 "validate: 304, reuse body" if stored_etag == server_etag
 else "validate: 200, replace body"
 )
 print(age, action)

The first line reuses without validation; the other two validate and reuse after a 304. Set server_etag to "release-b": the stale cases become 200, while the 59-second case still reuses the stored response. That is the permitted visibility delay the freshness policy buys in exchange for lower latency and origin load.

The contract worth asserting

Test matching and changed validators, freshness at the boundary, and the selected encoding. Also decide what should happen during an origin outage. HTTP can permit stale reuse under defined conditions or extensions; must-revalidate prohibits reusing the response once stale without successful validation, even when disconnected. This increases correctness pressure at the cost of availability. A validator alone makes no such promise.

A useful release record therefore states the cache policy, selected representation, observed conditional status, and tolerated update delay. Requiring two validator headers and one 304 cannot prove that every cache has current bytes, prevent all bandwidth waste, or replace testing the actual intermediary configuration.

Sources

RFC 9111: HTTP Caching, sections 4.1–4.3 and 5.2 on variants, age, validation, and directives, checked 2026-10-15.
RFC 9110: HTTP Semantics, sections 8.8, 13.1.2, and 13.1.5 on validators and comparison, checked 2026-10-15.

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 explains how to verify the policy at the public edge. The header below is the repository’s intended configuration, not a fresh observation of production.

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.

Assumes the article’s complete enforcing CSP with no more-specific script allowance. Report-Only does not block. The three checks shown are required evidence, not completed tests.

The threat surface you delete by not having a script lane

A page that executes no own or third-party script removes the client-side script dependencies that would otherwise need patching and review. An effective no-script CSP blocks injected script execution in conforming browsers, but HTML injection can still change text, links, and page structure. Trackers can also use images, navigation, or server logs without JavaScript. This site separately avoids third-party browser dependencies; that is a broader requirement than removing script tags. Browser-bundle dependency drift disappears when there is no bundle, while build-tool and server dependencies remain. 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 server delivers a policy that the browser enforces. The example Caddy configuration in this repository specifies:

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. With this complete policy and no more specific script allowance, a conforming browser refuses page scripts, inline handlers, and JavaScript URLs. A Content-Security-Policy-Report-Only header would only report violations, not block them. Later additions of script-src-elem or script-src-attr need review because they can override the fallback for their respective script categories.

The build verifier checks generated artifacts for executable scripts, handlers, and URLs. It cannot prove that a reverse proxy serves the intended CSP. Fetch representative HTML, error pages, and redirect destinations separately; inspect the actual enforcing header and test browser behavior. Source inspection, response inspection, and browser execution are three distinct checks.

What the static structure buys after the removal

With no scripting, the content model reverts to something closer to published documents. Caching operates on HTTP representations, not on a page’s later DOM mutations. Static output makes those representations easy to inspect and version; an ETag and freshness policy still depend on server configuration. 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 script-managed state, no client-side rendering, and no feedback that needs a JavaScript view model. Native links, keyboard navigation, CSS behavior, and elements such as details can still provide interaction. 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 useful evidence for the response sampled. It does not prove universal browser support or that every route has the same policy. Keep the underlying content safe to render, protect publishing access, and maintain the generator and server. The boundary is defensible precisely when its limits are explicit.

Sources

W3C: Content Security Policy Level 3, policy delivery, script directives, and directive fallback (working draft), checked 2026-10-15.
MDN: Content Security Policy (script-src), directives that disable script execution, checked 2026-10-15.
PortSwigger: What is cross-site scripting (XSS)?, script injection and its consequences, checked 2026-10-15.
OWASP: Content Security Policy, CSP as a defense-in-depth control, checked 2026-10-15.