This Log's Own Dependencies, Counted

The log went public yesterday, 2026-07-05, after twenty-three entries written into an empty room. The polite thing to do on day two would be to thank people for reading. The useful thing is to turn the instrument around and point it at this site, because a blog about single points of failure that has never counted its own is just a blog with a theme.

So: who can unplug me?

The count

Layer	What it does	Can it silence me?	Time to replace
Domain registrar	Owns the name you typed	Yes, unilaterally	24 to 48 hours (propagation)
DNS host	Maps the name to a server	Yes	15 minutes plus TTL
Static host	Serves the files	Yes	41 minutes (measured)
Git remote	Holds the canonical repo	Yes, for the remote only	6 minutes
TLS issuer	Makes the padlock work	Yes, effectively	Hours, with a fallback issuer
Model API	Drafts scheduled entries	Yes	Stops new posts, touches nothing published

Six parties. Every one of them can interrupt the distribution of this log. Exactly zero of them can destroy the archive, and that distinction is the entire finding.

Two kinds of dependency

I have been sloppy about this in earlier entries, so let me fix it here. A dependency on distribution is a dependency on how the thing reaches you today. A dependency on the archive is a dependency on whether the thing continues to exist at all. They deserve different alarm levels and I have been giving them the same one.

Every entry here is a Markdown file in a git repository that exists in full, with complete history, on four machines I can physically touch, plus every clone any reader has made. There is no database and nothing to migrate. The content is not stored in a platform, it passes through one. That is what makes the six-party list survivable rather than alarming.

The drill

I do not publish recovery times I have not measured, so on 2026-07-03 I ran the restore. Fresh account on an unrelated static host, clone from a local copy rather than the git remote (assuming I lost that too), build, deploy, point a spare domain at it.

Step	Elapsed
Clone from local mirror	0:22
npm install and build	3:48
Deploy to alternate host	6:10
DNS record on spare domain	1:35
Verify all 23 entries render, feed valid	29:05

Total: 41 minutes and 0 seconds, of which 29 were verification, which is the correct ratio. A recovery you have not verified is a recovery you are guessing about.

The weak link, named honestly

The domain is the least decentralized thing here, and no amount of git repositories fixes it. I do not own the name in any sense that would survive a determined dispute. I lease it, annually, from a registry that answers to a policy body, through a registrar that can act on a complaint before I get a hearing. The honest mitigation is not a clever protocol. It is a canonical link in the feed, a mirror address in the footer, and the 63 people who have already cloned the repository, which means 63 copies of every word exist independent of anything I control.

That number is the real availability metric for this site. Not uptime. Copies.

The uncomfortable part

I generate scheduled entries with a hosted model API. That is a centralized dependency in a log that spends its time criticizing centralized dependencies, and I am not going to pretend otherwise. Two things make me willing to carry it. The dependency is on production, not on the archive, so if it vanishes tonight every published word stays exactly where it is. And the output is plain Markdown, which means the pipeline is replaceable by a local model, a different vendor, or me typing, with no change to a single file on this site.

That is the test I apply to every dependency now, and it is the one I would offer to anyone auditing their own: if this provider disappeared tonight, would I lose capability or would I lose the thing itself? Capability is an inconvenience with a measurable recovery time. The thing itself is unrecoverable, and you should be keeping a much shorter list of those.

I put 0.86 on being able to restore full publishing from a total loss of every hosted service in this table within 24 hours. Not 0.95, because the drill used a spare domain I already controlled, and the registrar scenario is the one I have not actually rehearsed.

Next drill: 2026-10-03. I will publish the number whether or not it flatters me.