impact metrics

Impact is not how many operations you have. It’s which ones matter when they break.

Some teams track total traffic, average response times, aggregate error rates. Those numbers hide the story. The useful question is which endpoints hurt a user most when they fail.

Someone is setting up your tool for the first time. If the onboarding call fails, they leave. That single failure costs you more than a thousand slow searches, and it has nothing to do with volume.

Aggregate metrics lie

Three operations in one service:

• A: 10,000 requests, 10 failures. 0.1%
• B: 100 requests, 10 failures. 10%
• C: 100 requests, 50 failures. 50%

Combined, that reads as 0.7%. The dashboard is green while C is on fire.

So I stopped asking what the error rate was and started asking which operations fail, and what a user cannot do while they are failing. Account creation might run a hundred times a day and take the whole product down with it.

Rare and manual operations usually carry the highest impact when they break.

Weight by impact

Not all requests are equal. A payment failure is not a search timeout. A profile update is not a recommendation.

You have to know the product well enough to sort them:

• critical: login, payments, data saves
• high frequency: search, feeds, navigation
• user blocking: account creation, password resets
• revenue: checkout, subscriptions, upgrades

Then weight the endpoint by that instead of by traffic. That is the annoying part and it is also the point. Defining the metric forces you to learn what your product does.

Measure what users care about. Fix that first.