Original, source-backed articles about running small systems, static sites, HTTP, DNS, TLS, and operations.
Posts are original articles written for this site. Each one is script-free, source-backed, and tied to the same operational reality the rest of the site records: how a small, static, publicly served system is built, secured, and kept honest.
Credential expiry needs an enforcing verifier
A credential expires only when the system deciding access checks an applicable deadline. Writing an expiry date in an inventory does not change what a database or API accepts. A short lifetime can reduce the period during which a stolen credential starts new access, but its effect depends on the authentication mechanism and on what happens to sessions or other credentials already created with it.
...
ETags and conditional requests avoid work
A 304 is useful only when the old representation really remains an acceptable substitute. ETag supplies the origin’s version claim; it does not independently verify that claim. An incorrect tag can make conditional requests efficiently preserve wrong content. Test both unchanged data and meaningful changes before counting reduced transfers as a performance improvement.
...
Multi-stage builds need a tested runtime boundary
A multistage Dockerfile can compile software in one stage and copy selected outputs into another stage that becomes the runtime image. The final stage inherits its own base and the files explicitly copied into it, rather than automatically inheriting the builder’s compiler, source tree, and package caches. This creates a useful boundary, but the author must still identify everything the program needs when it executes.
...
Set a TLS version floor and test its boundary
A TLS version policy defines which handshakes an endpoint accepts. Prefer an explicit minimum over assuming that a library’s changing defaults match your requirements. A maximum is a separate constraint: freezing it unnecessarily can prevent adoption of a newer supported protocol. Neither setting replaces certificate verification, suitable algorithms, or timely security updates.
...
Alerts tell you what to read
An alert should give its reader a useful first investigation, not merely a red indicator. Name the observed condition, affected scope, persistence window, responsible team, and next evidence to inspect. These details are part of the rule’s behavior: test them with the trigger instead of treating notification text as decoration added after the incident.
...
Histograms preserve the latency shape
A mean can make an uncomfortable service look fast. If ninety-five requests take 50 milliseconds and five take two seconds, the average is only 147.5 milliseconds. A latency histogram retains more information about that slow minority without storing every request. What it preserves is a bucketed approximation of the distribution, not the complete original observations or an automatically exact percentile.
...
Progressive rollouts need evidence and a recovery path
A progressive rollout increases exposure while checking whether the new version behaves acceptably. It can discover a regression before every request uses that version. It does not make a change reversible by itself, guarantee that only the selected percentage is affected, or require a feature flag. Traffic routing, instance replacement, and feature exposure are different controls that can participate in the same release plan.
...
An error budget names the failures you allow
An objective such as “99.9% reliable” is incomplete until someone can classify an observation. Reliable for which users, at which boundary, over what window, and according to which outcome? An error budget gives the permitted failures a quantity only after those questions have answers. Its first engineering task is defining the population and the good-event rule, not choosing a dashboard color.
...
