Build, publish, observe, and restore a small service without losing the last known-good state.
Use this path when the question is not only “does it work?” but also “what evidence lets us replace it or recover it?” The notes keep artifact boundaries, rollback windows, and routine maintenance visible.
Restart policies need a rate limit
Use an explicit service type, bounded restart behavior, and start-rate limits that leave evidence in the journal.
A maintenance timer should leave its last result visible
Scheduling is only half the job; operators also need to see when the task last ran and how it ended.
Backups are only useful after a restore rehearsal
Choose a small recovery unit, verify it, and practice restoring it somewhere disposable.
Reliable defaults beat clever recovery
Keep the common path explicit, observable, and safe to repeat before adding recovery branches.
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.
Ship a static site and prove the edge agrees
Build, publish, and confirm with the same evidence the notes describe, end to end.