When deployment frequency and rollback rates disagree
Rising ship counts look healthy until reverse deployments climb in the same window. Here is how to read that tension without blaming a single team.
A team can celebrate more production deploys while the people who reverse those deploys grow quieter about how often they intervene. Application analytics that only champion deployment frequency miss the second half of the story.
Start by aligning definitions. Count a rollback when a release is withdrawn or replaced because of a defect introduced by that release — not every configuration tweak. Then place rollback events on the same calendar as deploys. Clusters after weekend ships, after schema-heavy changes, or after releases owned by rotating contractors tell different stories.
Reliability closes the triangle. If error budgets hold after rollbacks, you may be catching issues early. If user-facing reliability dips even when rollbacks succeed quickly, the release path is still taxing people and systems. Frequency alone never settles that question.