▲A work in progress
Runbook pages.
pages from a runbook
I write about things I build, problems I get stuck on, and whatever I'm learning along the way.
- 15 posts
- 47 topics
- 6 mo writing
- 2026 since
A retry without a budget is a fan-out generator.
A lock without an owner token is a timeout with a race attached.
If a Redis key has no owner and no expiry decision, it is already an operational problem. It just has not paged anyone yet.
Read the library source when the runtime behavior and the documentation disagree.
A useful runbook preserves the wrong turns. The final fix alone is rarely enough to help during the next incident.
Shipped
I built leakferret after one too many secret findings arrived at the most expensive point, after the value had entered git history. Its Rust engine finds likely credentials, checks documented fixtures, verifies supported providers, and can rewrite a literal to an environment lookup. The same engine backs the CLI, editor extension, MCP server, and release packages.
10,800+ downloads across
- crates.io
- npm
- RubyGems
- Go
- VS Code
- Open VSX
- GitHub Actions
- MCP Registry
Reading shelf
- Designing Data-Intensive ApplicationsI went back for the chapters on replication and transactions. They made more sense after operating the failure modes.
- Site Reliability EngineeringThe incident response and capacity chapters still earn their place on the shelf.
- Working Effectively with Legacy CodeOlder than much of the code it would help with, and still painfully accurate.
- Database InternalsEnough detail to explain the machinery without pretending I am writing a storage engine.
- Understanding Distributed SystemsA compact map of the problems that become real only after something ships.
- Working with Ruby ThreadsThe GVL chapter remains the best starting point, even though Ruby gained several new concurrency tools.
- The Code BookI read this as a teenager. It was my first serious invitation into security.
Topics
Writing timeline
April 2026 hover a dot to see what published when September 2026
Recent writing
-
One slow consumer can stop every RabbitMQ publisher
A slow RabbitMQ consumer fills one queue until shared resource alarms block every publisher. Trace the pressure, the loss boundaries, and the safer designs.
-
Now depends on who you ask
UTC fixes how time is written down. It does not settle whose clock won, when a transaction sampled it, or which event happened first.
-
The event was delivered. The work was not.
Event fan-out can reach every subscriber while the business operation remains unfinished. See which consumers need completion state, retries, and an owner.