Short, reproducible notes about static websites and small service operations.
These notes focus on the boring parts of running a small service: clear defaults, observable failures, repeatable releases, and recovery that has been exercised before it is needed.
The current collection is organized around four recurring questions:
What does the protocol or server actually promise?
Which headers, files, and logs make that promise visible?
What can be checked without changing production state?
Which source should an operator read when the example is not enough?
Examples are intentionally small. Adapt paths, users, and policies to the environment where you run them. Every note ends with a short source list instead of copying vendor documentation into this site.
A release manifest should name every published byte
One aggregate digest is useful, but a sorted per-file manifest tells you exactly what changed or went missing.
Redirects and error codes should preserve the story
Check the method, Location header, and cache behavior before choosing a redirect or an error status.
Read the public edge in two commands
Two small read-only helpers turn the public endpoint into evidence you can inspect before and after a release.
A release is not complete until the public edge agrees
Build once, inspect the output, then exercise representative public routes before replacing the live directory.
A postmortem should leave a fact record
A postmortem is a chronological map from detected symptom to verified fix, backed by the commands that produced each fact.
Range requests should prove which bytes were selected
A 206 response is useful only when its boundaries and total size describe the bytes that were returned.
HTTP methods are a promise about side effects
Get the method boundary right once, and OPTIONS, HEAD, and idempotent writes stop being a surprise.
Validators decide whether a cached copy is still the answer
Conditionals are the cache’s second clock; a 304 means the stored copy is still the answer.
