Reliability coverage in this archive spans 18 posts from Jul 2016 to Jan 2026 and focuses on reliability, delivery speed, and cost discipline as one system, not three separate concerns. The strongest adjacent threads are architecture, sre, and ai. Recurring title motifs include production, ai, outage, and taught.
Reliable agents aren't prompted into existence. They're engineered -- with bounded tools, validation at every step, explicit recovery paths, and the same discipline you'd apply to any production system. Here's how I build them in Go.
Your AI system can return 200 OK and still be wrong, unsafe, or confidently hallucinating. Here's how to detect, contain, and learn from AI incidents -- drawing from the same IR principles that work for traditional systems.
AI agents that can take actions are fundamentally different from chatbots. The engineering bar must match the blast radius.
Betting on a single model provider is like having a single database with no failover. Here is why multi-model is the only sane production strategy.
December 7 reminded everyone that us-east-1 is a single point of failure for half the internet. Again. I am annoyed.
Good incident response is not about preventing failure. It is about failing well. Lessons from a decade of on-call, including NATO and telecom-scale operations.
Practical database reliability from running Postgres at the fintech startup and at large enterprises. Includes config examples, migration patterns, and the operational habits that actually prevent outages.
Teams love saying they do chaos engineering. Few actually have hypotheses. Even fewer fix what they find.
Every team says they want zero downtime. Few want to do the boring work that actually gets them there. Here's what that boring work looks like.
Most load tests produce comforting numbers instead of useful answers. Here's what I learned the hard way about getting honest results.
Most SLOs are dashboards nobody acts on. Here's how to pick indicators that reflect real users, set targets grounded in data, and make error budgets actually change how your team ships.
Failure is not an edge case. It is the default state you temporarily hold off with good engineering. A few hard-won rules for building systems that bend instead of shatter.
Hard-won patterns for reliable background job processing -- queues, retries, idempotency, and the failures that taught me to care about all three.
Hard-won lessons from designing distributed systems that survive real-world failures -- timeouts, retries, bulkheads, and the operational habits that actually keep things running.
The SRE hype train has everyone copying Google's playbook without asking whether it fits. Here's what actually matters when you're not running planet-scale infrastructure.
Chaos engineering isn't just for the big players. Here's how a small team can start breaking things deliberately and actually learn from it.
Every pipeline I've built at the fintech startup broke at some point. Here's the design approach that made them recoverable instead of catastrophic.
Production incidents show where architecture bends and where it breaks. These lessons focus on designing for failure, limiting blast radius, and making recovery routine.