|8 min read
What Is MTBBC and Why Your Team Should Track It
Mean Time Between Breaking Changes is the missing engineering metric for API-first teams. Here's how to calculate it, what good looks like, and how to improve it.
Mean Time Between Breaking Changes is the missing engineering metric for API-first teams. Here's how to calculate it, what good looks like, and how to improve it.
AI-assisted coding accelerates shipping but introduces subtle API contract drift that cascades across teams. Here's what's going wrong and how to catch it.
Unmonitored API changes cost more than you think. Engineering hours, customer trust, partner churn, and on-call burnout compound with every incident.
A comprehensive reference of what constitutes a breaking API change — from field renames and type changes to status codes and authentication shifts.
A realistic incident postmortem of a field rename that cascaded through a microservices architecture. The change wasn't wrong — it was uninformed.
Versioning is a release strategy, not a prevention strategy. By the time you need v2, you've already broken v1 consumers.
GraphQL's flexibility creates a false sense of safety. Removed fields, type changes, and required arguments all return 200 status codes — making breakage invisible to standard monitoring.
Protobuf's wire compatibility rules give false confidence. Removed fields return silent default values, type changes cause truncation, and renamed fields break JSON serialization.