The fleet looks healthy. Region B does not.

The fleet dashboard says 99.8% of completed exports succeeded. Meanwhile, a customer in region B has seen one in five fail. It would be convenient if one of those numbers were simply wrong. In this example, both are right.

The difference is whose work each number counts. Here is an invented ten-minute Dispatch packet. These are completed eligible exports, not every job the service accepted.

Region	Completed exports	Failed exports
A	9,900	0
B	100	20

Twenty failures, two very different piles

Put all 10,000 completed exports in one pile. Twenty failed, so the fleet failure fraction is 20 divided by 10,000: 0.2%. The other 99.8% succeeded. Now pull out region B’s hundred exports. The same twenty failures are still there, but they occupy one fifth of this much smaller pile: 20%.

The denominator, the count underneath the division, changed from all fleet completions to B’s completions. Region B supplied only one hundredth of the fleet’s completed work. Its painful result therefore has relatively little weight in the fleet total, even though it is the entire experience for the customer asking about B.

Averaging the regional percentages would give (0% + 20%) / 2 = 10%. That treats A’s 9,900 completions and B’s 100 as equally large contributions. For the fleet fraction, add the event counts first and then divide. Keep the regional view too; the large pile should not make the small one disappear from the investigation.

Carry the operation, population and interval with the number when handing it to someone else. “Completed exports in region B over these ten minutes” keeps the next person on the same question.

A hundred waiting is not a hundred per second

Suppose a completion counter reads 1,000, then 1,600 ten minutes later. It has added 600 events in 600 seconds, or one completion per second on average. A counter normally increases until a reset or restart. If it reset during that interval, subtracting the two endpoints can give the wrong answer. Prometheus rate accounts for observed counter resets, but still needs enough samples and the correct series identity: the particular labeled counter being measured.

Now look at a queue showing 100 exports waiting. That is a current value, called a gauge, which can rise or fall. It is not a speed. Watching it over time tells you whether the waiting line grows or drains; one reading says how many are waiting now.

A distribution keeps information about many observations, such as the durations of individual exports. That lets you ask how much work took longer than a threshold. The counter, gauge and distribution answer different questions even when all three concern the same service.

An odometer and speedometer offer a familiar distinction between accumulated count and pace, except that an application’s counter may reset when its process restarts. Say the unit alongside the number: 600 completions in 600 seconds is one completion per second; 20 failed completions among 100 completions is 20%. One division uses time, the other eligible work. Calling both a “failure rate” without that context leaves the reader to reconstruct what was counted.

How many reports missed five minutes?

If customers need their reports within five minutes, ask that question directly: count the operations exceeding five minutes and divide by the same eligible population. A p99 latency answers a different question. Imagine lining up the measured durations from shortest to longest: p99 marks a duration at about 99% of the way through that ordered group, leaving roughly 1% above it. A histogram estimates that position from its buckets. Keep the population and time window attached; this number does not automatically give the fraction beyond your particular deadline.

Nor can two instance p99 values be averaged into a fleet p99. Each has already discarded most of the observations that produced it. Knowing two selected positions does not tell you how all the durations would line up together.

Compatible histogram bucket counts can be combined instead. Those buckets count observations in duration ranges, retaining information the two precomputed percentiles alone cannot restore. For the five-minute question, counting results on either side of the deadline often gives the customer’s answer more directly.

Give the number a label that reveals its limits

Return to the ten-minute packet and calculate the pace as well as the fractions. Region A completed 9,900 exports in 600 seconds: 16.5 per second. Region B completed 100 in 600 seconds: about 0.167 per second. Together that is about 16.667 completed exports per second. B handled much less work, but its 20% failure fraction was one hundred times the fleet’s 0.2%.

A useful regional label is “Failed completed exports / all completed exports, region B, last 10 minutes.” It is longer than “failure rate,” and for good reason: it tells the next reader exactly which work got into the calculation.

It also reveals who is missing. If accepted jobs can disappear before completing, none of these completion-only fractions sees them. Add an accepted-to-completed view to follow that work. The customer in B no longer has to argue with a healthy fleet chart, and the customer whose report never finished has somewhere to be counted too.

Sources

Prometheus metric types, rate functions, and histograms describe the mechanics. Every count in the example is synthetic.