Reliability
Service level objectives for a personal website. The scale is faintly absurd, which is the point: the method survives contact with small systems, so it can be trusted near big ones.
The objectives
Reader surfaces answer
The homepage, the articles index, an article page and the feed return 200 to a probe.
The MCP endpoint answers
POST /mcp/ completes an initialize handshake.
ask_matt answers the canary correctly
A synonym-shaped question returns the essay it should, not a confident wrong answer.
ask_matt answers promptly
The canary question completes within a tolerable wait for an agent mid-conversation.
The semantic index covers the corpus
Every published post is present in the committed embeddings index this deploy shipped with.
The running numbers are fresh
The committed Strava snapshot is recent enough for its date to be a credential rather than a confession.
The golden questions stay green
Every retrieval eval in data/ask-evals.json passes against the shipped index and thresholds.
The error budget
The availability target of 99.5% buys a budget of 0 failed probes out of the 8 recorded so far this quarter; 0 have been spent. At this sample size the budget rounds to almost nothing, which is honest: with sparse measurements you get a conscience, not a confidence interval. The arithmetic gets interesting exactly as the probe history gets long, and the file only grows one honest row at a time.
How this is measured
- Probes run from
npm run slo, which exercises the reader pages, the feed and the MCP endpoint in production and commits the results. The page renders that committed history and fetches nothing at request time. Last recorded run: 29 Jul 2026, one of 2 this quarter. - The ask_matt probe is a canary, not a ping. It asks a synonym-shaped question and checks the right essay comes back, because the failure mode that matters does not look like an error: a missing semantic index degrades into confident wrong answers while every status code stays 200.
- Two of the objectives never need a probe at all: index coverage and snapshot freshness are computed from the repository at build time, so a deploy that would breach them arrives already knowing.