Why p99log

Most dashboards default to the average. Average latency, average load, average response time. It’s the number that makes everything look fine.

p99 is the number that tells you the truth. It is the 99th percentile: one request in a hundred was slower than this. That one might have hit a cold cache, waited behind a saturated connection pool, or retried into a dependency that was already timing out. The mean is useful for capacity planning. p99 is where users start noticing the implementation.

That is why the name fits. The happy path is not unimportant; it is just rarely where the architecture earns its keep. The tail is where backpressure, timeout budgets, idempotency, queue depth, and retry policy stop being implementation details and become the system.

Why write it down

For the last seven years, I have worked on distributed systems: queues that must not lose messages, services that need a useful degraded mode, and retry paths that need to distinguish temporary failure from feedback-loop fuel. Recently that has included agentic systems, where an LLM can plan, call tools, and take several steps before a human sees the premise it started from.

That work produces a lot of knowledge that is too situational for a design doc and too durable for a Slack thread: a rate limit that changes the shape of a worker pool, an incident that exposes an unaccounted-for queue, a metric that looked healthy until it was split by tenant or region. Writing it down forces the causal chain to be explicit. Publishing it means the useful parts do not disappear when the project, team, or company changes.

Log, not essays

The “log” part is deliberate. Think systems log, not literary journal: timestamped entries, written close enough to the work that the uncertainty is still visible. Some posts will be a single observation. Others will be a full breakdown after the relevant graphs, traces, and failed assumptions have had time to settle. I would rather publish an accurate account of the tradeoffs than a smooth retrospective that pretends the answer was obvious.